Notification Data Retention
Summary
Retention is Not implemented. No reviewed code path deletes a row from any of the seven tables. There is no cleanup job, no purge endpoint, no archival routine, no time-to-live and no retention configuration.
Audience
DevOps engineers, engineers, architects, security reviewers, support and product owners.
Verified absence
- No
Remove,RemoveRange,ExecuteDeleteorExecuteDeleteAsynccall anywhere in the service. - No hosted service, background timer or scheduled job performing cleanup — the only hosted service is the event consumer.
- No API endpoint that deletes a message, template, recipient, attempt, audit row or ledger entry.
- No retention window, age threshold or maximum-row setting in the options type.
- No soft-delete flag, no archive table and no partition-by-date scheme.
- No database-level time-to-live or scheduled maintenance declared in the migration.
Every table in the schema is therefore append-only or update-in-place, and grows monotonically.
Growth characteristics
| Table | Growth driver | Bound |
|---|---|---|
| Audit log | events × recipients × channels × pipeline stages | None |
| Delivery attempts | one row per attempt, up to the retry maximum per message | None |
| Messages | one row per recipient and channel per event | None |
| Idempotency ledger | one row per consumed event, forever | None |
| Recipients | one row per distinct recipient, plus one per test send | None |
| Templates | one row per version created | None |
| Preferences | not written at runtime | Static |
The audit log grows fastest by a wide margin, since it records a row per stage rather than per message. The idempotency ledger is the one that can never be trimmed without weakening duplicate suppression, because an absent row is indistinguishable from an unprocessed event.
Consequences
Query cost rises over time. The statistics endpoint performs eight unbounded aggregate scans, and the failed-queue and audit reads scan on columns no index leads with. All degrade as volume accumulates.
Message bodies are stored in full. Rendered subject and body text — which for notification content routinely contains personal data such as names, employee codes, leave dates and payroll references — is retained indefinitely with no expiry.
No deletion path for data-subject requests. Because nothing deletes, there is no implemented mechanism to remove an individual's notification history, and the absence of foreign keys means any future deletion must remove dependent rows in explicit order.
These are recorded as verified technical facts. Any compliance conclusion drawn from them requires confirmation against the platform's data-protection position, which this documentation does not assert.
Classification
Not implemented.
Requires confirmation
Retention periods for messages, attempts, audit and the idempotency ledger; whether archival is planned; and the data-protection position on indefinite retention of rendered notification content all require confirmation.
Related Articles
See Also
Keywords
- Notification database
- Retention
- Draft database documentation
Source References
microservices/src/notification-service/Infrastructure/NotificationDbContext.csmicroservices/src/notification-service/Application/NotificationDispatcher.csmicroservices/src/notification-service/Api/NotificationEndpoints.csmicroservices/src/notification-service/Program.csmicroservices/src/notification-service/Application/NotificationOptions.cs
Revision Information
- Status: Draft
- Last reviewed: 2026-07-21
- Review cycle: Quarterly