Notification Persistence Architecture

Summary

Persistence is accessed directly. Application services and API handlers both take NotificationDbContext as a constructor or parameter dependency and query it with LINQ. There is no repository, no unit-of-work abstraction and no data-access layer between the domain and Entity Framework.

Audience

Engineers, architects, QA, support and security reviewers.

Persistence architecture

Ownership boundaries

The notification schema is owned exclusively by the Notification Service. No other service in the reviewed source declares a context, entity or migration against it, and the Notification Service declares no entity belonging to another module's schema.

The three legacy tables are owned by the monolith's shared application context. Nothing in the reviewed source replicates, synchronises or migrates data between the two models.

Access path

Five components touch the context directly:

Component	Access
Minimal API handlers	Read and write across all seven tables
NotificationDispatcher	Read and write — messages, recipients, attempts, audit, idempotency
TemplateEngine	Read-only — templates
PreferenceEvaluator	Read-only — preferences
DefaultTemplateSeeder	Insert-only — templates, at startup

The context is registered with the default scoped lifetime, so each HTTP request and each consumed message resolves its own instance.

No abstraction layer

There is no IRepository, no IUnitOfWork, no specification type and no query object. Handlers compose LINQ against DbSet properties inline, which is why query-level concerns such as tenant scoping vary endpoint by endpoint rather than being enforced centrally.

Canonical persistence

The extracted schema is the canonical store for event-driven notifications, delivery attempts, audit and idempotency. The legacy tables remain the store that the portal's user-facing notification and template screens read. Neither is a superset of the other.

Classification

Transitional.

Requires confirmation

Whether a data-access abstraction is planned, and which store is canonical for user-facing notification history, require confirmation.

Related Articles

• DbContexts
• Query patterns
• Tenant isolation

See Also

• Transactions
• Notification technical architecture

Keywords

• Notification database
• Persistence Architecture
• Draft database documentation

Source References

• microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
• microservices/src/notification-service/Application/NotificationDispatcher.cs
• microservices/src/notification-service/Api/NotificationEndpoints.cs
• microservices/src/notification-service/Application/TemplateEngine.cs
• microservices/src/notification-service/Application/PreferenceEvaluator.cs
• microservices/src/notification-service/Seed/DefaultTemplateSeeder.cs
• Data/AppDbContext.cs

Revision Information

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