Design an Event-Driven Notification Hub

Problem framing: a hub decoupling producers from channels

An event-driven notification hub is the central system that takes events published by many internal services and turns them into notifications delivered to users across many channels — web push, mobile push, SMS, email, and in-app. The fact that defines the architecture is decoupling: producers (the order service, the payment service, the social service) publish events to topics without knowing who is subscribed or how they want to be reached, and the hub resolves each event into the right notifications on the right channels for the right users. Without the hub, every producer would have to know every user's preferences and integrate every channel — an N-times-M mess. The hub collapses that to N producers publishing and M channels delivering, with one routing brain between.

So the spine is: ingest events via pub/sub, resolve each event against topic subscriptions and per-user preferences into concrete delivery intents, and deliver them across channels with at-least-once reliability and idempotent deduplication, honoring ordering, priority, batching, and quiet hours. State the framing up front: this is a pub/sub routing-and-delivery platform whose job is to decouple producers from channels and deliver reliably, and the hard parts are fan-out, preference resolution, and exactly-once-feeling delivery over unreliable channels.