Notification Lifecycle
Business Purpose
Make each event's path and terminal processing outcome understandable to business, QA and support stakeholders.
Actors
Originating modules, the notification consumer, recipient and preference data owners, channel providers, recipients and support operators.
Business Flow
Duplicate events stop without creating a second message. Stale events are treated as processed. For accepted events, each distinct channel is evaluated independently, so one channel may send while another is suppressed or fails.
Responsibilities
Event producers supply stable event identifiers, occurrence time, tenant and payload. Service owners keep resolver mappings and templates aligned. Support uses audit stages to identify where a message stopped.
Business Rules
Processing outcomes include processed, duplicate, stale, no template, no recipient, suppressed and failed. If any message records are created, the event outcome becomes processed even when all created messages later fail delivery.
Integrations
Event consumption is restricted to mapped event types. Recipient data, templates, preferences and channel senders participate in processing; audit and processed-event records provide traceability.
Limitations
The event-level “processed” outcome is not a delivery-success indicator. An unexpected infrastructure failure can cause reprocessing, while the idempotency record prevents duplicate completed work.
Requires Confirmation
Confirm the accepted event-age policy, business handling for partially delivered events, reconciliation frequency and which failures require human escalation.
Source References
microservices/src/notification-service/Application/NotificationDispatcher.csmicroservices/src/notification-service/Messaging/NotificationEventConsumer.csmicroservices/src/notification-service/Messaging/NotificationEventEnvelope.cs
Related Articles
See Also
Keywords
Lifecycle, duplicate, stale, suppression, processing outcome.
Revision Information
Draft; reviewed 2026-07-21; next quarterly review 2026-10-21.