Concepts
Fan-Out
The process of taking one event or request and distributing work to multiple downstream consumers, services, users, or projections.
Concepts Covered
- Fan-out on write
- Fan-out on read
- Write amplification
- Read amplification
- Downstream consumers
- Hot users and hot groups
- Queue lag
- Product tradeoffs
Definition
Fan-out means one action causes work to spread to many recipients, systems, records, or projections.
Examples:
- one like event updates counters, notifications, ranking, and analytics
- one user post is inserted into many follower feeds
- one group message creates delivery work for many members and devices
- one notification is sent to multiple user devices
Fan-out is the moment one piece of work becomes many pieces of work.
The Pain That Forces Fan-Out
At small scale, a system can compute things directly when needed.
Example:
user opens feed -> query recent posts from everyone they follow
That can work when the user follows a few people and the dataset is small.
But a social product eventually has users who follow thousands of accounts, creators with millions of followers, public groups with huge membership, and events that many systems need to react to.
The product wants fast reads, fast writes, and rich downstream behavior. Fan-out is the tradeoff space between those goals.
The Naive Version
A naive feed system might build the feed on every read:
1. User opens feed.
2. Query all followed users.
3. Fetch recent posts from each followed user.
4. Rank and merge results.
5. Return feed.
This is simple, but the read becomes expensive. If the user follows 5,000 accounts, every feed load performs a large aggregation.
A naive write-heavy alternative might copy every new post into every follower's inbox immediately:
1. Creator posts.
2. Find all followers.
3. Insert post into every follower feed.
4. Return success.
This makes reads fast, but a creator with millions of followers creates a massive write burst.
Neither approach is universally correct. Fan-out is the decision about where the work happens.
Mental Model
Fan-out asks:
Should we distribute work when the event happens, or when the user reads?
Fan-out-on-write spends work early to make later reads cheap.
Fan-out-on-read delays work to keep writes cheap, but reads become more expensive.
Many large systems use a hybrid.
Fan-Out On Write
Fan-out-on-write performs distribution when the event happens.
Example:
creator posts -> write post reference into follower inboxes now
Benefits:
- reads are fast
- user inboxes are precomputed
- push or notification work can start early
Costs:
- writes can become huge
- hot creators or groups create write spikes
- retries can duplicate work without idempotency
- storage grows because data is copied
Fan-Out On Read
Fan-out-on-read performs distribution when the user asks for data.
Example:
user opens feed -> gather posts from followed accounts now
Benefits:
- writes stay cheap
- no need to copy every event to every recipient
- easier to apply fresh ranking logic
Costs:
- reads become slower and more complex
- high-fan-in users can be expensive
- repeated reads may recompute similar work
- caching becomes important
Concrete Example: Likes
For Instagram-style likes, one like can fan out to:
- counter projections
- notification candidates
- ranking features
- activity logs
- analytics aggregates
The core like should not synchronously wait for every downstream effect. The source write can commit, then downstream fan-out can happen through events and workers.
What Fan-Out Guarantees
Fan-out is not a guarantee by itself. It is a workload shape.
It can help:
- move work away from the request path
- make reads faster
- keep downstream systems decoupled
- support product-specific projections
It does not automatically solve:
- hot keys
- duplicate downstream work
- queue lag
- ordering
- backpressure
- storage amplification
Operational Reality
Watch:
- fan-out task creation rate
- recipient expansion latency
- queue depth
- duplicate task rate
- hot users, hot posts, or hot groups
- oldest pending fan-out task
- downstream consumer lag
- storage amplification from precomputed views
Failure modes:
- One action creates too many downstream writes.
- Slow consumers delay product features.
- Synchronous fan-out makes user actions fragile.
- Duplicate events create duplicate fan-out.
- High-follower accounts create extreme load.
- Large group delivery starves normal traffic.
Related Topics
Knowledge links
Use these links to understand what to know first, where this idea appears, and what to study next.
Prerequisites
Read these first if this topic feels unfamiliar.
Used In Systems
System studies where this idea appears in context.
Related Concepts
Core ideas that connect to this topic.