Skip to main content

Notification Service Anatomy

Summary​

The service centers on one application service, NotificationDispatcher, that orchestrates a consumed event through resolution, preference evaluation, rendering, message creation, delivery and audit. It collaborates with EventNotificationResolver, TemplateEngine, PreferenceEvaluator, RetryPolicy and IChannelSenderRegistry.

Collaborators​

Event coverage​

EventNotificationResolver.SupportedEventTypes enumerates the event types the resolver and consumer understand. Verified coverage spans Employee, Leave, Payroll, Document, Platform (tenant provisioning), Expense, Asset (six lifecycle events), Performance (seven lifecycle events), Training/LMS (ten events) and Helpdesk (ten ticket events). Each event maps to a template key, a recipient projection and default channels; a _ => Array.Empty<...>() fallthrough means unrecognized events produce no intents.

Recipient resolution​

The resolver deserializes each event payload to its contract record, extracts template variables and projects a recipient. Recipient type is chosen per event — employee (labor:{id}), user, or role (for example PayrollAdmin, HR, HelpdeskAdmin) when no individual subject exists. Helpdesk events can produce multiple recipients (requester and assignee), de-duplicated by type and reference.

Channels per event​

Most events default to in-app plus email (InAppEmail); payroll freeze defaults to in-app only. Email is only delivered when an address is resolvable for the recipient. The Notification:EventChannels option can override channels per event type without a code change.

Retry entry point​

NotificationDispatcher.RetryMessageAsync re-runs delivery for an existing message (resetting it to Pending), used by the admin retry endpoint. It reconstructs a minimal envelope so audit rows keep their event and correlation lineage.

Verified absence​

There is no NotificationEngine, NotificationProcessor, NotificationDispatcher worker daemon, QueueProcessor or NotificationHealth type. The dispatcher is a scoped application service invoked per event.

Requires Confirmation​

Whether Workflow and Recruitment events are intended to be resolved here requires confirmation; they are absent from SupportedEventTypes.

Source References​

  • microservices/src/notification-service/Application/NotificationDispatcher.cs
  • microservices/src/notification-service/Application/EventNotificationResolver.cs
  • microservices/src/notification-service/Application/Abstractions.cs

See Also​

Keywords​

Notification service, dispatcher, resolver, orchestration, event coverage.

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Next review: 2026-10-21