Skip to content

Case study: Notification system

Design a notification pipeline: a durable queue between fast producers and flaky providers, retries with breakers, priorities, and back-pressure when the queue fills.

30 min9 steps

By the end you can
  • Size sender concurrency, queue partitions and outage backlog with Little's law
  • Design at-least-once delivery with idempotency keys, collapse keys and a dead-letter queue
  • Protect providers and the pipeline with backoff, circuit breakers, bulkheads and priorities
  • Predict how provider errors, outages and slowdowns surface to callers

Requirements

Features

  • Push/SMS/email; preferences, quiet hours, caps, status, retries

Targets

  • Accept <50 ms independent of providers; 2FA seconds; marketing waits

Delivery

  • At-least-once; suppress duplicates where channel permits

Why must accepting a notification not depend on the push provider's health?

Answer this step to continue.

What this lesson simplifies

  • The provider is a simulated service with a latency distribution; real APNs and FCM limits and feedback are discussed only.
  • A queue partition is consumed one message at a time, so partitions bound sender parallelism in the simulator, as in a partitioned log.
  • The runnable cell runs 1,000 notifications/s with a 1,000-message queue.

Sources

  1. Apple. Sending notification requests to APNs.
  2. Google. Firebase Cloud Messaging documentation.
  3. M. Brooker. Exponential Backoff And Jitter, 2015.

Reviewed by Content lead on . Revision 1.