Skip to main content

Notification Database Documentation

Summary​

Complete Draft database documentation for Notification persistence. The extracted service owns one persistence context, NotificationDbContext, over a dedicated PostgreSQL database with the default schema notification, containing 7 tables and 14 indexes created by 1 migration. The legacy monolith separately owns 3 notification tables inside its shared context.

Audience​

Developers, QA engineers, support engineers, DevOps engineers, security engineers, solution architects and implementation partners.

Overview​

Notification persistence is deliberately flat. NotificationDbContext maps seven independent entities — templates, recipients, messages, delivery attempts, preferences, an append-only audit log and an idempotency ledger — using fluent configuration for table names, string lengths, required flags and indexes only.

Three characteristics define the model and are documented throughout this section:

  • No declared relationships. Identifier columns such as the message's recipient reference and the attempt's message reference are plain values. No HasOne, HasMany, navigation property or foreign-key constraint exists anywhere in the model or the migration.
  • No global query filter. The context declares no tenant filter; the service is documented in source as a cross-tenant consumer, and tenant scoping is applied per query where it is applied at all.
  • No conversions, no concurrency tokens. Every enumerated concept is stored as a plain string; no value converter, owned type, JSON column, row version or concurrency token is declared.

The monolith retains its own three notification tables in the shared application context, and those do carry tenant query filters with a super-admin bypass. The two persistence models are unrelated in shape and are not synchronised.

Documentation map​

Start with the database overview, persistence architecture and DbContexts.

Per-entity storage is covered in notification storage, template storage, recipient storage, preference storage, delivery storage, retry storage, audit storage, idempotency storage and statistics storage.

Model-level references cover entity mappings, relationships, indexes and constraints, value conversions and tenant isolation.

Runtime behavior is covered in query patterns, transactions and concurrency. Lifecycle and governance are covered in migrations, development seeding, retention and database testing.

The authoritative schema reference, database limitations and source map close the section.

Classification​

Transitional. The extracted schema is Implemented; relationships, concurrency control, retention and database testing are Not implemented; tenant isolation is Partial.

Requires confirmation​

Database ownership and hosting for the extracted schema, whether foreign-key constraints and retention are intended, and the migration path from the monolith's notification tables require confirmation.

See Also​

Keywords​

  • Notification database
  • Persistence
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
  • microservices/src/notification-service/Domain/NotificationEntities.cs
  • microservices/src/notification-service/Infrastructure/Migrations/20260705113059_InitialNotificationSchema.cs
  • microservices/src/notification-service/Seed/DefaultTemplateSeeder.cs
  • Data/AppDbContext.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly