Design a Pub/Sub Fanout System

Messaging & Event-DrivenMediumdesign-pubsub-fanout

Design one-to-many event distribution where a single publish reaches hundreds of independent subscribers, each of whom may be slow, broken, or temporarily gone.

Publish-SubscribeFanoutDead Letter QueueBackpressure

Traffic & Capacity Estimates:

200k publishes/second · up to 500 subscribers per topic · at-least-once delivery

Functional Requirements

•Deliver each published message to every active subscription of a topic independently.
•Support filtered subscriptions so a subscriber receives only matching events.
•Retry failed deliveries with backoff and move poison messages to a dead-letter queue.
•Let a new subscriber start from now, or from the beginning of the retained window.

Non-Functional Requirements

•One slow subscriber must not delay delivery to the others.
•At-least-once delivery with visible, bounded redelivery — never silent loss.
•Publish latency must stay flat as the subscriber count grows.

Back-of-the-Envelope Math

200k publishes/s * 500 subscribers = 100M deliveries/second at worst case — fanout is the real load, not publish volume.
A subscriber offline for 1 hour accumulates 720M messages; retention policy decides whether that's caught up or dropped.

Key Architectural Trade-offs

Fanout on write (copy per subscriber — fast reads, enormous write amplification) vs fanout on read (subscribers pull from a shared log — cheap, subscribers must track position).
Push delivery is low-latency and needs backpressure and endpoint health tracking; pull delivery lets the consumer set its own pace.
Per-subscriber queues isolate failure and multiply storage; a shared log with per-subscriber offsets is compact and couples retention decisions.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow