Notification Database¶
Why This Exists¶
This document defines conceptual database responsibilities for the Notification Domain. It does not define physical SQL implementation.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
Notification data must support operational delivery, retries, read tracking, escalation, and audit history across channels and source domains.
Conceptual Tables Or Collections¶
| Table or collection | Responsibility |
|---|---|
| notification_requests | Request source, type, reason, recipient rule, priority, and source reference. |
| notifications | Message instance, recipient, lifecycle state, priority, schedule reference, and template version. |
| notification_recipients | Resolved recipient references and recipient metadata needed for delivery. |
| notification_channels | Channel configuration, provider, status, and capability metadata. |
| notification_preferences | User, role, team, or organization channel and timing preferences. |
| notification_templates | Approved template content, variables, channel, language, version, and status. |
| notification_schedules | Immediate, delayed, recurring, and deadline-relative schedules. |
| notification_reminders | Reminder rules linked to source references and schedules. |
| notification_delivery_attempts | Channel delivery attempts, provider responses, status, and timestamps. |
| notification_read_receipts | Recipient read, acknowledgement, and dismissal records. |
| notification_escalations | Escalation records, reason, threshold, target, and status. |
| notification_communication_history | Append-style history of delivery, read, acknowledgement, failure, and escalation events. |
| notification_channel_callbacks | Provider callback payload references and processing state. |
| notification_audit_log | Audit records for preference changes, template approvals, and critical delivery decisions. |
Indexing Considerations¶
Notification should support indexes for:
organization_id.recipient_reference.source_domainandsource_reference_id.notification_type.priority.delivery_status.read_status.scheduled_for.created_at.provider_message_id.
Audit Requirements¶
Audit logging is required for:
- Critical notification requests.
- Preference changes.
- Template approvals and deprecations.
- Delivery failure and retry decisions.
- Escalation creation and resolution.
- Read and acknowledgement events for approval-sensitive workflows.
Data Retention¶
Communication history should preserve operational traceability while respecting privacy, consent, and channel-specific retention rules. Message content may need different retention from metadata depending on sensitivity and legal requirements.
Provider Callback Handling¶
External channel providers may send asynchronous delivery callbacks. Notification must validate, deduplicate, and attach callbacks to delivery attempts without letting providers become the source of business facts.