Notification Preference Storage

Summary

NotificationPreferences stores per-recipient channel opt-outs for an event type. The table is read-only at runtime — no reviewed code path inserts, updates or deletes a preference row.

Audience

Engineers, architects, QA, support and security reviewers.

Reference Content

The verified reference material for this topic is set out in the sections below.

Ownership

Owned by NotificationDbContext. Read by PreferenceEvaluator during dispatch. Written by nothing in the reviewed source.

Columns

Column	Type	Constraint
Id	GUID	Primary key
TenantId	string	Max length 80, nullable
RecipientType	string	Max length 40, required
ExternalRef	string	Max length 200, required
EventType	string	Max length 160, required — the literal * means all events
Channel	string	Max length 40, required
Enabled	bool	Entity default true
CreatedOnUtc	timestamp	—
UpdatedOnUtc	timestamp	—

Indexes

Index	Columns	Unique
UX_Preferences_Scope	tenant, type, external reference, event type, channel	Yes

This is the widest unique index in the schema, at five columns.

Opt-out model

Absence of a row means enabled. Notifications therefore flow by default and a row exists only to silence a specific channel and event for a specific recipient.

Resolution precedence

The evaluator loads the candidate rows for the tenant, recipient and channel, then selects an exact event-type match first and falls back to a wildcard row. When neither exists the channel is treated as enabled. A suppressed channel is audited and contributes a suppressed outcome to the event.

Verified absence of a write path

No API endpoint, no seeder and no application service creates, updates or deletes a preference row. The table can only be populated outside the application. This makes the feature Partial: the read and enforcement side is implemented, the management side is not.

Lifecycle

Not applicable at runtime — rows are never created or removed by reviewed code.

Classification

Partial — enforcement is Implemented; preference management is Not implemented.

Requires confirmation

How preference rows are intended to be created, and whether a management surface is planned, require confirmation.

Related Articles

• Query patterns
• Database limitations
• Schema reference

See Also

• Indexes and constraints
• Notification channel architecture

Keywords

• Notification database
• Preference Storage
• Draft database documentation

Source References

• microservices/src/notification-service/Infrastructure/NotificationDbContext.cs
• microservices/src/notification-service/Domain/NotificationEntities.cs
• microservices/src/notification-service/Application/PreferenceEvaluator.cs
• microservices/src/notification-service/Application/NotificationDispatcher.cs

Revision Information

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