Is a notification system just publish-subscribe?

Publish-subscribe is usually part of the backbone, but it is not the whole system. The bus moves events between producers and consumers. A notification system also handles recipient resolution, policy checks, user preferences, template rendering, channel selection, provider calls, retries, idempotency, delivery status, and audit records.

Should product services send notifications directly?

Usually no, except for very small or temporary features. Product services should publish clean domain events with enough facts for downstream processing. Direct sending mixes business logic with preferences, copy, channels, and failure handling. That makes later changes harder and spreads provider-specific behaviour through systems that should not know about it.

What is the difference between push and polling in notification delivery?

With push, the server or provider actively delivers a message to the client or channel when it is ready. With polling, the client periodically asks whether anything new exists. Push gives faster perceived delivery but depends on connection and provider behaviour. Polling is simpler in some systems, but can waste work and feel less immediate.

Notification System

A notification system is the product infrastructure that turns domain events into messages delivered through channels such as email, push, SMS, Slack, or in-app feeds. It separates the event that happened from decisions about eligibility, recipients, preferences, wording, delivery, retries, and tracking.

The need appears when product services start telling users about things directly. A billing service sends payment emails, a comments service sends mention pushes, and a deployment service posts to chat. Soon each service contains preference logic, templates, retry code, provider details, and special cases. That coupling makes simple changes risky: adding a channel or pausing noisy messages requires edits across unrelated business systems.

A typical pipeline starts with a domain event published by the service that owns the fact, such as a user being mentioned or an invoice becoming overdue. An event bus or queue buffers it and fans it out. A notification orchestrator decides whether the event should produce notifications, resolves recipients, checks policy and preferences, renders templates, chooses channels, sends through channel adapters, then records status for audit, retry, and support.

The important design choice is ownership of decisions. The domain service owns that the event happened, not the wording or delivery path. Preferences own opt-in, quiet hours, and channel rules. Templates own content. Channel adapters own provider-specific calls. The notification service owns orchestration, idempotency, retries, and delivery records. This is commonly misunderstood as just calling a provider API from product code.

The trade-off is operational complexity. Queues, workers, templates, provider integrations, deduplication, retries, and observability all need care. Delivery is often asynchronous, so the user action and the message are not one atomic operation. Ordering, duplicate sends, stale preferences, and provider outages must be handled explicitly. The honest answer to how much machinery you need is: it depends on volume, channels, compliance needs, and failure tolerance.

Engineers meet notification systems in event-driven backends, user preference services, messaging workers, mobile push integrations, email pipelines, and in-app notification feeds. In design reviews, the useful test is whether you can draw the path from event to delivered message and name the component that owns each decision. If not, notification logic is probably leaking into product services.

Go deeper

User SystemsThe Notification SystemDraw the pipeline from a domain event to a delivered notification, and name the component that owns each decision along it.Open the lesson

Common questions

Is a notification system just publish-subscribe?: Publish-subscribe is usually part of the backbone, but it is not the whole system. The bus moves events between producers and consumers. A notification system also handles recipient resolution, policy checks, user preferences, template rendering, channel selection, provider calls, retries, idempotency, delivery status, and audit records.
Should product services send notifications directly?: Usually no, except for very small or temporary features. Product services should publish clean domain events with enough facts for downstream processing. Direct sending mixes business logic with preferences, copy, channels, and failure handling. That makes later changes harder and spreads provider-specific behaviour through systems that should not know about it.
What is the difference between push and polling in notification delivery?: With push, the server or provider actively delivers a message to the client or channel when it is ready. With polling, the client periodically asks whether anything new exists. Push gives faster perceived delivery but depends on connection and provider behaviour. Polling is simpler in some systems, but can waste work and feel less immediate.

Every term