05.01 · Concept · Free
The Notification System
Draw the pipeline from a domain event to a delivered notification, and name the component that owns each decision along it.
Curated for this lesson1/3
Communication & Notifications
Notifications: Everything you need in 45 minutes - Google I/O 2016
Closest match: a focused notifications talk from Firebase, long enough to cover delivery decisions conceptually.
A production notification pipeline turns domain events into delivered messages through separated ownership: producers publish facts, queues buffer work, notification services decide eligibility, preferences enforce user policy, templates shape content, channel adapters send through providers, and delivery tracking handles retries, status, idempotency, and auditability.
What this lesson answers
- how should notification systems be architected
- who owns notification delivery decisions
- domain event to notification pipeline
Notes
A notification system starts with something meaningful happening in the product: an order shipped, a comment mentioned you, a payment failed, a deployment finished. That domain event should be owned by the business service that knows it happened, but that service should not also decide every notification detail. Its job is to publish a clean event such as UserMentioned or InvoiceOverdue, with enough identifiers and facts for downstream systems to act on it.
The usual pipeline is event producer, event bus or queue, notification orchestrator, preference and policy checks, template rendering, channel selection, provider delivery, and delivery tracking. The event bus owns buffering and fan-out. The notification service owns whether this event should become a notification. Preferences own user opt-in, quiet hours, and channel rules. Templates own wording. Channel adapters own how to talk to email, SMS, push, Slack, or in-app systems. Providers own final transport, while your system owns retries, idempotency, status, and audit records.
A useful mental model is a factory line, not a function call. The domain service drops a labeled package onto a conveyor belt. Each station makes one kind of decision: is this eligible, who receives it, what should it say, where should it go, can it be sent now, did it succeed, should it retry? This separation lets you add a new channel, change a template, pause noisy notifications, or replay failed deliveries without modifying the checkout, comments, or billing service.
The common misconception is that “sending a notification” is just calling an API when something happens. That works for a toy feature, but in production it mixes business logic, user policy, formatting, delivery mechanics, and failure handling in one place. After this lesson, you should be able to draw the path from domain event to delivered message, name which component owns each decision, and spot when a design is coupling the product service too tightly to the notification channel.
Common questions
- Why should domain services publish events instead of sending notifications directly?
- The domain service knows that something happened, but it should not own wording, user preferences, channel routing, provider details, or retry behaviour. Publishing a clean domain event keeps product logic separate from communication logic, making notifications easier to change without editing checkout, billing, comments, or similar services.
- What components are usually involved in a notification pipeline?
- A typical pipeline has an event-producing service, a bus or queue, a notification orchestrator, policy and preference checks, template rendering, channel selection, channel-specific adapters, external delivery providers, and delivery tracking. Each stage owns a narrow decision, which keeps the system understandable and operationally manageable.
- What decisions belong in user notification preferences?
- Preferences should own user-controlled communication policy: whether the user opted in, which channels are allowed, quiet-hour behaviour, and similar delivery constraints. They should not decide the business meaning of an event or the provider mechanics. Their job is to answer whether a candidate notification may be sent to that user.
Short definition: what is Notification System?