Design an Event-Driven Notification Hub

Problem statement

Design an event-driven notification hub that lets many microservices publish domain events — order shipped, friend request received, payment failed, security alert, comment reply — and delivers the right message to the right user through web push, mobile push (APNs/FCM), in-app inbox, email, and SMS, respecting subscriptions, user preferences, quiet hours, frequency caps, and unsubscribe state.

This is not a function that calls SMTP. It is a decoupled fabric. Publishers must never know which channels exist, which providers are healthy, what each user opted into, or how retries work. They publish one typed event with a topic, user reference, payload, and priority. The hub owns everything downstream: subscription matching, preference resolution, deduplication, template rendering, localization, channel selection, provider throttling, delivery, receipts, and audit.

Why the problem is distinctive

A chat system moves bytes between connected parties. A notification hub moves meaning between a business event and a human who may be offline, on three devices, in two time zones, with one channel muted. The hard properties are:

• Fan-out asymmetry. One event can target one user (password reset) or tens of millions (breaking-news broadcast). The pipeline must absorb both without re-architecture.
• Multi-channel idempotence. The user must receive the alert once, even though three channels are racing and two retries occur.
• Preference races. A user can unsubscribe while their event is mid-flight. The hub must resolve preferences as late as safely possible without blocking delivery forever.
• Channel heterogeneity. APNs has per-device tokens and collapse IDs, FCM has topics and priorities, SMS has carrier filtering and per-country regulations, email has deliverability reputation, in-app has per-user ordered feeds.

The four architectural planes

1. Ingestion plane: validated, schema-checked, idempotent event intake from internal publishers onto a durable bus.
2. Resolution plane: subscription matching, preference evaluation, frequency control, dedup, and channel selection.
3. Delivery plane: channel adapters with provider-specific protocols, throttling, retries, dead-lettering, and receipt collection.
4. Feedback plane: delivery events, opens, clicks, unsubscribes, complaints, analytics, and deliverability monitoring feeding back into resolution.

A strong answer keeps these planes separate. The delivery plane may degrade one channel without stopping others. The feedback plane may lag without blocking delivery. The resolution plane must stay consistent even when everything else is on fire.

Public operating baseline versus design assumptions

Public evidence shows this category is real and large. OneSignal publicly reports delivering billions of notifications per day across mobile, web, and email channels. Twitter engineering historically described a fan-out service writing precomputed timelines at peak rates on the order of hundreds of thousands of writes per second. Pinterest engineering has published Kafka deployments handling hundreds of billions of messages per day, and Discord has published message volumes in the trillions per year. These are cited company figures for context, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes: 500 million registered users, 150 million daily active users, 2 billion notification requests per day, average ingestion of roughly 23,000 events per second with a 6x event peak, and an average fan-out multiplier of 4 delivery tasks per ingested event. Unless tied to a citation, every number is a stated design assumption.