Notification and Outbox Storage
Audience
Developers, QA and support engineers, data reviewers, implementation partners, solution architects, privacy reviewers and security reviewers.
Reference Content
Summary
Lifecycle delivery evidence is distributed. Extracted services use local outbox and/or processed-event ledgers, Notification Service stores delivery state, and the compatibility application has separate notification and queue models.
Delivery topology
Context capabilities
| Context | Publication intent | Consumption idempotency |
|---|---|---|
| Recruitment | Outbox | Processed-event ledger |
| Employee | Outbox | No selected ledger |
| Payroll | Outbox | Processed-event ledger |
| Attendance | Outbox | No selected ledger |
| Leave | Outbox | No selected ledger |
| Asset | Outbox | Processed-event ledger |
| Notification | No outbox object | Processed-event ledger |
| Compatibility | Integration outbox and notification queues | No equivalent lifecycle ledger confirmed |
Notification model
Notification Service stores templates, recipients, messages, delivery attempts, preferences, audit evidence and processed events. The inspected resolver does not currently map Recruitment onboarding events.
Semantics
An outbox row proves publication intent, not successful publication or delivery. A delivery attempt proves an attempt, not user acknowledgement. Cleanup and replay governance require confirmation.
Requires confirmation
Unless explicitly confirmed above, production migration governance, rollback, reconciliation, retention, privacy, performance, concurrency and operational ownership require confirmation.
Source References
microservices/src/notification-service/Infrastructure/NotificationDbContext.csmicroservices/src/notification-service/Application/EventNotificationResolver.cs
Related Articles
See Also
Keywords
- Onboarding database
- Offboarding database
- Lifecycle persistence
Revision Information
- Status: Draft
- Last reviewed: 2026-07-20
- Review cycle: Quarterly