LMS Notification Consumer
Summary
Source-backed Notification recognition, idempotency, retry, and outcome behavior for Training contracts.
Audience
Engineering, integration, QA, support, architecture, security, and notification owners.
Reference Content
Notification recognizes TrainingAssigned, TrainingStarted, TrainingCompleted, AssessmentPassed, AssessmentFailed, CertificateIssued, CertificateExpiringSoon, TrainingSessionScheduled, and TrainingSessionRescheduled. It deserializes compatible messages into a common internal projection, validates sufficient tenant/course context, resolves a recipient category and notification intent, applies delivery preferences, and records delivery attempts. Recipient, template, channel, and payload details are intentionally excluded.
Before work, the dispatcher checks processed-event storage by event identity. Duplicate identities are audited and skipped; the unique constraint adds persistence protection. Unexpected consumer infrastructure failures cause negative acknowledgement with requeue. Individual notification delivery uses bounded retry and records a terminal Failed message when attempts are exhausted. A delivery failure does not necessarily fail event dispatch; the event is subsequently recorded as processed.
The expiry contract is recognized and templated but not emitted by Training. Template governance, retention, requeue ceiling, and end-to-end delivery guarantees require confirmation.
Source References
microservices/src/notification-service/Messaging/NotificationEventConsumer.csmicroservices/src/notification-service/Application/EventNotificationResolver.csmicroservices/src/notification-service/Application/NotificationDispatcher.csmicroservices/src/notification-service/Infrastructure/NotificationDbContext.cs
Related Articles
See Also
Keywords
- LMS events
- Training contracts
- Source-backed integration
Revision Information
- Status: Draft
- Last reviewed: 2026-07-17
- Review cycle: Quarterly