Fan-Out on Write
establishedSummary
On write, precompute and push the result to all relevant readers' caches or feed stores. Reads become pure cache lookups with no aggregation, shifting latency cost from read time to write time.
Problem
Read latency on aggregated views (news feeds, activity streams, personalized content) is too high when computed at request time from raw data. Read traffic is orders of magnitude higher than write traffic.
Description
Fan-out on write inverts the typical read path. Instead of computing a user's news feed at read time (expensive: join user's followed accounts, fetch recent posts, sort by timestamp), the system computes the feed entry at write time, when the post is created, and delivers it directly to each follower's feed store.
At read time, a feed request is a single O(1) cache lookup: typically a Redis LRANGE on a sorted set, returning pre-ranked post IDs in microseconds. The database is not touched during reads.
Implementation: each user has a Redis sorted set (feed:{user_id}) of post IDs scored by publish timestamp. When user A posts, a background worker enqueues a fanout job that iterates A's follower list and issues a ZADD to each follower's feed sorted set, followed by a ZREMRANGEBYRANK to trim the set to the max feed length (e.g., 1000 posts). The write cost is O(followers).
Celebrity problem: a user with 30 million followers requires 30 million ZADD operations per post. At 10 posts/day, that is 300 million write operations per day to serve one account. This is operationally intractable for pure fan-out on write. The industry solution is hybrid fan-out: - Normal users (< N followers): fan-out on write - High-fan-out users (> N followers): fan-in on read (merge celebrity posts
at read time with the pre-computed feed from followed normal users)
Twitter/X uses this hybrid model. The threshold N is operationally tuned.
Precomputed feeds can go stale if a post is deleted or edited: the fan-out must be reversed (fan-out on delete), or feeds must carry enough metadata to validate post existence at read time.
Tradeoffs
Reads become O(1) cache lookups; sub-millisecond feed retrieval at any scale
One post write becomes N cache writes (N = follower count); amplification factor is the fan-out degree
Feed caches require storage proportional to user count × feed depth; memory-intensive
Requires special-case hybrid fan-out for high-follower accounts; adds code complexity
Post edits and deletes require fan-out invalidation: complex to implement correctly
When to use
Read traffic is significantly higher than write traffic (>10:1 ratio)
The write amplification cost amortizes across many reads; lower ratios favor fan-in on read
Read latency is a primary SLO (sub-10ms feed loads)
Fan-out on write eliminates all read-time computation; achieves cache-speed reads
Fan-out degree is bounded (typical user has < 10k followers)
Write amplification is manageable when fan-out degree is low; high fan-out requires hybrid model
When not to use
Users have extremely high follower counts (celebrity problem)
30M-follower account produces 30M cache writes per post; hybrid fan-out required above a threshold
Write throughput is the bottleneck, not read latency
Fan-out on write amplifies writes by the average fan-out degree; worsens the bottleneck
Content is frequently edited or deleted after publication
Reversing fan-out on edit or delete requires complex fan-out logic for each change event
Operational Requirements
Implement hybrid fan-out with a configurable follower threshold
Accounts above threshold (e.g., 10k followers) use fan-in on read to avoid write amplification
Size fan-out worker queue to absorb burst write events
Viral posts spike fan-out queue depth; workers must drain faster than posts arrive at peak
Trim feed sorted sets to maximum length on each fan-out write
Unbounded growth per feed set will exhaust Redis memory; ZREMRANGEBYRANK after ZADD
Monitor fan-out queue depth and worker lag separately from feed read latency
Fan-out queue backup delays when followers see new posts; alert on lag > SLO
Characteristics
Technologies
Canonical
Alternatives
Relationships
Evolves from
Complements
Basis
Industry-standard pattern at Twitter, Facebook, Instagram; operational tradeoffs well-documented in engineering posts
Related Architecture Knowledge
Outbound: this entity affects
Fan-out on write multiplies each post event into one write per follower; at high follower counts this produces write amplification that can saturate the write path for popular accounts.
Full relationship →Inbound: affects this entity
Fan-out on read and fan-out on write are used together in a hybrid social feed model: normal accounts use fan-out on write for fast reads; high-follower accounts use fan-out on read to avoid write amplification.
Full relationship →Redis sorted sets are the standard implementation substrate for fan-out-on-write news feed architectures. Each user's feed is a sorted set keyed by user_id, with post IDs scored by timestamp, enabling O(log N) per-follower write and O(1) feed reads with ZREVRANGE.
Tradeoffs
- ·Fan-out-on-write requires Redis memory proportional to total_users * avg_feed_size
- ·High follower accounts create write hotspots: requires hybrid fan-out strategy
- ·Deleted posts require a compensating fan-out sweep to remove the post ID from all follower feeds