Source-Confirmed Mappings

This page records what is confirmed directly from source code today. It is intentionally narrower than team or business ownership.

Important boundary

These items are confirmed from code:

• DB connection types and whether a service uses primary or replica DB connections
• registered NestJS modules and route prefixes
• RabbitMQ queues a service publishes to or consumes from
• retry and dead-letter settings defined in queue config

These items still need team confirmation:

• official business ownership of each DB schema or table
• whether a service is the authoritative writer versus a reader or helper
• operational trigger rules used by support teams
• DLQ replay procedures, monitoring ownership, and manual recovery steps

Team-confirmed clarifications

The following were confirmed by the team after the source pass:

• these services are part of the Antrix system of record
• services do not write directly into another service's tables; cross-service interaction is done by calling the other service's endpoint
• NGOSS, NOC Grid, NOCPro, TMF, and Vital are owned on the Antrix side, but are exposed as endpoints for external sources to call
• most queue triggers are API-call driven
• DLQ handling relies on automatic retry after a configured number of attempts
• the minimum required backend for local work is authentication; additional services depend on the feature you are touching
• external dependencies are generally reached through development or staging endpoints

DB usage matrix

Service	Confirmed DB usage from code	Notes
mvp1-authentication-service	one MariaDB primary connection via DB_*	no replica config in code
mvp1-setting-service	one MariaDB primary connection via DB_*	no replica config in code
mvp2-data-service	three MariaDB connections: intt-db, next-db, intt-source-db, all currently fed by DB_*	code confirms multiple named connections, not distinct env groups
mvp3-gsb-service	one MariaDB primary connection via DB_*	no replica config in code
mvp3-ticket-service	one MariaDB primary via DB_* and one replica via DB_REPLICA_*	replica constant TICKET_DB_REPLICA
mvp3-ngoss-service	one MariaDB primary via DB_*	no replica config in code
mvp3-nocgrid-service	one MariaDB primary via DB_* and one replica via DB_REPLICA_*	replica constant NOCGRID_DB_REPLICA
mvp3-nocpro-service	one MariaDB primary via DB_*	no replica config in code
mvp3-tmf-service	one MariaDB primary via DB_*	no replica config in code
mvp6-vital-service	one MariaDB primary via DB_*	no replica config in code
queue services	DB env exists in .env.sample	actual write or read responsibility needs deeper service-level review

Module-to-service mapping

Confirmed from route and module registration

Domain	Service	Confirmed module or route evidence
NGOSS	mvp3-ngoss-service	NgossModule mounted under /ngoss
NOC Grid	mvp3-nocgrid-service	KciModule and NttModule mounted under /nocgrid/kci and /nocgrid/ntt
NOCPro	mvp3-nocpro-service	NocproModule mounted under /nocpro
TMF	mvp3-tmf-service	TmfModule registered in routing module, controller exposed under TMF service
Vital	mvp6-vital-service	VitalModule registered in routing module, Vital controllers in service

Interpretation note

Code confirms the technical host service for these modules. It does not fully prove whether product or operations teams consider the same service to be the sole business owner.

Queue publish and consume matrix

Consumers

Queue worker	Consumes
mvp3-caution-report-queue-service	intt_caution_report_queue
mvp3-changedp-queue-service	intt_alu_queue, intt_zte_queue, intt_fiberhome_queue, intt_huawei_queue
mvp3-ctt-queue-service	intt_ctt_queue
mvp3-gsb-queue-service	intt_gsb_queue
mvp3-kci-queue-service	intt_kci_queue
mvp6-tass-queue-service	intt_tass_queue
mvp6-vital-queue-service	intt_vital_queue

Producers confirmed from code

Producer service	Queue target	Trigger pattern seen in code
mvp3-gsb-service	intt_gsb_queue	`send('gsb-create-dp'
mvp3-gsb-service	intt_alu_queue, intt_zte_queue, intt_fiberhome_queue, intt_huawei_queue	device-specific emit(queueName, ...) calls
mvp3-ticket-service	intt_kci_queue	emits create-kci, create-ctt-related-kci, update-unlinked-ctt, update-kci, closure-kci, troubleshoot-kci, trigger-mcmc-poll
mvp3-ticket-service	intt_ctt_queue	emits or sends tmf-update-ctt-list from ctt and ntt modules
mvp3-ngoss-service	intt_kci_queue	emits create-kci
mvp3-ngoss-service	intt_ctt_queue	sends tmf-update-ctt-list
mvp3-nocpro-service	intt_kci_queue	emits create-kci
mvp3-nocpro-service	intt_ctt_queue	sends tmf-update-ctt-list
mvp3-tmf-service	intt_ctt_queue	sends controller-driven TMF update patterns
mvp6-vital-service	intt_vital_queue	emits vital-send-ctt, vital-update-ctt-activity
mvp6-vital-queue-service	intt_ctt_queue	sends tmf-update-ctt-list
mvp6-tass-queue-service	intt_ctt_queue	sends tmf-update-ctt-list
mvp6-tass-queue-service	intt_tass_tm_category_delay_queue	emits taas-enrich-tm-category

Dead-letter and retry settings

Queue config host	Queue	Retry config	Dead-letter or TTL config
mvp3-ctt-queue-service consumer	intt_ctt_queue	not defined in bootstrap consumer config	dead-letter to intt_ctt_dlq
mvp3-ticket-service producer modules	intt_ctt_queue	retryAttempts: 3, retryDelay: 3000	dead-letter to intt_ctt_dlq
mvp3-ngoss-service producer	intt_ctt_queue	retryAttempts: 3, retryDelay: 3000	dead-letter to intt_ctt_dlq
mvp3-nocpro-service producer	intt_ctt_queue	retryAttempts: 3, retryDelay: 3000	dead-letter to intt_ctt_dlq
mvp3-tmf-service producer	intt_ctt_queue	retryAttempts: 3, retryDelay: 3000	dead-letter to intt_ctt_dlq
mvp6-vital-service producer	intt_vital_queue	retryAttempts: 3, retryDelay: 3000	dead-letter to intt_vital_dlq
mvp6-vital-queue-service consumer side config	intt_vital_queue	consumer bootstrap has no retryAttempts	dead-letter to intt_vital_dlq
mvp6-tass-queue-service consumer side config	intt_tass_queue	consumer bootstrap has no retryAttempts	dead-letter to intt_tass_dlq
mvp6-tass-queue-service delay producer	intt_tass_tm_category_delay_queue	retryAttempts: 3, retryDelay: 3000	TTL 120000, then dead-letter routes to intt_tass_queue

Still open

These points are still worth clarifying later:

1. exact schema or table ownership per service
2. standardized local PORT values for services that currently share default 3004
3. exact per-queue trigger list, if the team wants queue docs to be business-complete rather than architecture-complete
4. who monitors each DLQ operationally and what replay procedure is used