Notification Audit Storage

Summary

NotificationAuditLog is an append-only trail recording every stage an event or message passes through, keyed for correlation tracking. It is the most heavily indexed table in the schema.

Audience

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

Reference Content

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

Ownership

Owned by NotificationDbContext. Written by the dispatcher's audit helper at every stage and by the read-state endpoint. Read by the audit query endpoint.

Columns

Column	Type	Constraint
Id	GUID	Primary key
TenantId	string	Max length 80, nullable
EventId	GUID	Nullable
NotificationMessageId	GUID	Nullable — null for event-level stages
EventType	string	Max length 160, nullable
Stage	string	Max length 40, required
Detail	string	Max length 2000, nullable
CorrelationId	string	Max length 160, nullable
TraceId	string	Max length 64, nullable
OccurredOnUtc	timestamp	—

Indexes

Index	Columns	Unique
IX_Audit_EventId	event	No
IX_Audit_MessageId	message	No
IX_Audit_Correlation	correlation	No
IX_Audit_OccurredOn	occurrence timestamp	No

Four single-column indexes — one for each filter the audit endpoint accepts, plus one for its ordering column.

Stages

Thirteen stage values are defined as constants and stored as plain strings: received, duplicate, stale, template resolved, template missing, recipient resolved, suppressed, message created, delivered, delivery failed, retried, processed and read.

Twelve are written by the dispatcher across the processing pipeline; the read stage is written by the read-state API endpoint.

Write pattern

Every audit write is its own save. The helper adds one row and immediately calls save changes, so a single event that fans out across recipients and channels produces many separate audit round-trips. Detail text is truncated in application code to the mapped maximum before the row is added.

The trace identifier is captured from the active tracing activity when one exists, linking a stored audit row to a distributed trace.

Growth

Append-only with no cleanup. Audit volume scales with the number of events times recipients times channels times pipeline stages, and nothing removes rows. See retention.

Lifecycle

Insert-only. No reviewed code path updates or deletes an audit row.

Classification

Implemented.

Requires confirmation

Whether audit retention and archival are planned requires confirmation.

Related Articles

• Retention
• Query patterns
• Schema reference

See Also

• Transactions
• Notification logging and observability

Keywords

• Notification database
• Audit 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/NotificationDispatcher.cs
• microservices/src/notification-service/Api/NotificationEndpoints.cs
• microservices/src/notification-service/Infrastructure/Migrations/20260705113059_InitialNotificationSchema.cs

Revision Information

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