What it is
Fan-out is the decision of when a single event (a post, a message, a notification) turns into the multiple copies its many recipients will eventually see. Fan-out-on-write pushes the work to publish time: the moment something happens, the system writes a copy into every recipient's own list, so a later read is a single cheap lookup. Fan-out-on-read defers that work to request time: nothing is duplicated up front, and a read gathers together everything relevant from each source the reader cares about. Real systems almost never pick one exclusively — the interesting design work is choosing a threshold and building the hybrid, because the two approaches fail in opposite ways at opposite ends of the popularity distribution.
When it applies
- One producer's output needs to reach many consumers, and the number of consumers per producer varies enormously (a typical user has hundreds of followers, a small number of accounts have tens of millions).
- The read path must stay fast and cheap even though the underlying data is naturally organized by producer, not by consumer — feeds, chat delivery to devices, and notification broadcast all have this shape.
- It does not apply as a single fixed answer — a system's actual answer is almost always "fan-out-on-write below a threshold, fan-out-on-read (or a bounded merge) above it," not a pure choice of one over the other; treating it as binary is itself a mistake to avoid.
Tells in the problem
- "Users follow sources, sources publish, followers see a feed of what they follow" with a note that follower counts are highly skewed — the classic setup demanding a hybrid write/read fan-out with an explicit threshold.
- "A message must reach every device of every recipient" — fan-out is per-device, not just per-user, and the design needs a way to track delivery state at that finer granularity.
- "One event notifies millions of people" or "a burst where one action fans out to a huge audience" — the amplification point itself (a single request becoming millions of downstream writes) needs a paging/checkpointing strategy so a crash mid-fan-out doesn't restart from zero.
- Any mention of a small number of extreme outliers (a celebrity account, a huge broadcast group) alongside a much larger population of typical, small-scale participants — that split is exactly what forces a threshold-based hybrid rather than one uniform strategy.
- A requirement that a producer's own recent activity must be visible to them immediately, even though fan-out to others is asynchronous — solved by having the producer's own read path merge in their own unfanned-out recent items directly, sidestepping the fan-out lag entirely for the one reader who can't wait for it.
The classic mistake
Treating fan-out as a single global decision rather than doing the arithmetic per producer size is where designs go wrong — applying fan-out-on-write uniformly means a small number of huge producers generate an astronomical, sometimes system-breaking number of writes per event, while applying fan-out-on-read uniformly means every reader's request fans out into as many lookups as sources they follow, which is slow whenever that number is large. The fix is always the same shape: pick a threshold (based on what the read path can afford to merge live, not an arbitrary round number), fan out on write below it, and merge at read time above it — and back that threshold with the actual numbers (follower counts, read-path fetch budget) rather than asserting a hybrid exists without showing why the threshold sits where it does.
Questions to start with
- Design a News Feed — the canonical hybrid: a follower-count threshold splits normal accounts (fan-out on write) from huge ones (merged at read time), with the arithmetic that forces the split spelled out explicitly.
- Design a Chat Messaging System — fan-out at the finer grain of individual devices rather than users, and the write-time-versus-read-time trade-off restated for message delivery instead of feed reads.
- Design a Notification System — fan-out as the amplification point itself (one request becoming millions of per-user messages), with the operational concerns of checkpointed paging and priority lanes that keep a burst from starving normal traffic.