Notification service
One pipeline for every notification: recipient-list expansion with preferences, priority queues so OTPs beat campaigns, delayed digests, a dedup window and a DLQ.
What this design does
Every product grows a notification mess: marketing blasts starving password-reset OTPs, users double-notified across channels, digests firing at 3am. This design centralizes it: producers emit intents, a router expands recipient lists against preferences and quiet hours, priority queues guarantee transactional messages always cut the line, scheduled sends wait in a delayed queue, and a dedup window makes 'notify at most once per event per user' a property of the pipeline — not a hope. Failures park in a DLQ for humans instead of retry-looping forever.
The patterns it composes
- Recipient list (routing) — one intent expands to the right users, channels and locales
- Priority queue — OTPs and receipts always pre-empt marketing volume
- Delayed / scheduled delivery — digests and quiet-hours sends wait in the queue, not in cron scripts
- Deduplication window — event-id + user keyed — at-most-once per event per person
- Dead-letter channel — poison notifications park for inspection, never block the line
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.