Skip to main content

Notification Database Overview

Summary​

The extracted Notification Service owns one PostgreSQL database, addressed by a single named connection string and mapped to the default schema notification. That schema holds 7 tables and 14 indexes. The legacy monolith separately holds 3 notification tables inside its own shared database.

Audience​

Engineers, architects, QA, support, DevOps engineers and security reviewers.

Owned database​

Program.cs registers NotificationDbContext against PostgreSQL using a connection string resolved by the logical name NotificationDb. No connection value appears in this documentation.

OnModelCreating sets the default schema to notification, so every mapped table is created inside that schema rather than the database default.

Table inventory​

TablePurpose
NotificationTemplatesVersioned subject and body templates per tenant, key and channel
NotificationRecipientsDirectory of resolved recipients keyed by tenant, type and external reference
NotificationMessagesOne rendered notification bound to a channel and recipient
NotificationDeliveryAttemptsAppend-only record of each delivery attempt
NotificationPreferencesPer-recipient channel opt-out rows for an event type
NotificationAuditLogAppend-only stage-by-stage processing trail
ProcessedIntegrationEventsIdempotency ledger, one row per consumed event

Defining characteristics​

Three properties of the model are verified across every entity and recur throughout this section.

No relationships are declared. The model contains no HasOne, HasMany, WithOne or WithMany call, no navigation property on any entity, and the migration issues no foreign-key statement. Identifier columns that logically reference another table are plain values.

No global query filter. The context declares no HasQueryFilter. The source comment records this as deliberate — the service is described as a cross-tenant consumer and orchestrator that observes every tenant's events — with tenant scoping applied per query.

No conversions or concurrency control. No HasConversion, OwnsOne, OwnsMany, IsRowVersion, IsConcurrencyToken, HasDefaultValue, HasPrecision or OnDelete call exists. Every enumerated concept is persisted as a plain string.

Legacy persistence​

The monolith's shared context maps three notification tables and, unlike the extracted service, applies tenant query filters to all three with a super-admin bypass. See tenant isolation.

Current maturity​

Transitional. The extracted schema is complete and migrated for the operations it supports, but it coexists with an unrelated legacy model, and referential integrity, concurrency control and retention are absent.

Classification​

Transitional.

Requires confirmation​

Hosting and ownership of the extracted database, and whether the legacy tables are to be migrated or retired, require confirmation.

See Also​

Keywords​

  • Notification database
  • Database Overview
  • 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/Program.cs
  • Data/AppDbContext.cs

Revision Information​

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