Data Model (ERDs)

Each service owns its schema; there is no shared database (ADR-006). Per-service entity-relationship diagrams are kept as PDFs in docs/erd/ (viewable in any browser via the links below) rather than as Markdown, since they are generated diagrams, not prose.

Diagram	Scope
01 - Monolith (reference)	The legacy monolithic schema this platform replaces incrementally - useful context for why the domain looks the way it does
02 - Microservices (overview)	Cross-service overview: every service's schema on one map, with the (non-existent) foreign keys between services shown only conceptually
03 - Customer Service	Customer, Address, Document
04 - Product Catalog Service	Tariff, Addon, ProductOffering, TariffAddon
05 - Order Service	Order, OrderItem, SagaState
06 - Subscription Service	Subscription, MsisdnPool, SimCard
07 - Usage Service	Quota, UsageRecord, CdrEvent
08 - Billing Service	Invoice, InvoiceLine, BillCycle
09 - Payment Service	Payment, PaymentAttempt, Wallet
10 - Notification Service	NotificationTemplate, Notification, Channel (MongoDB)
11 - Ticket Service	Ticket, TicketComment, SLA

There is no published ERD yet for identity-service, campaign-service, dispute-service, or fraud-service (all added after the original ERD set) - their aggregates are documented in the Service Catalog instead.

Cross-service consistency

Since there is no shared database and no distributed transaction across services, consistency between two services' data is always eventual, driven by the same outbox/inbox event flow described in Events & Messaging. When you need to reason about "does service B's view of service A's data ever go stale, and for how long," start from the event catalog's producer/consumer table for the specific event involved, not from the schema alone.