Skip to main content
Pre-computing every user’s feed is a common optimization for social platforms, but it creates a serious corner case: celebrity accounts. Consider Lionel Messi with 100 million followers. A naive pre-computation (fan-out-on-write) strategy would push his post into every follower’s feed list. That single write operation could take minutes and involve duplicating the same post into 100 million lists. Two problems arise from this approach:
  • Massive write amplification: the system performs millions of writes for one post.
  • Wasted work: many followers may not open the app for days, so those writes are unnecessary.
By contrast, building feeds at read time (fan-out-on-read) avoids huge write spikes but increases read-time work. The practical solution is a hybrid approach that balances write and read costs.

​
Hybrid approach: push for normal users, pull for celebrities

Core idea:
  • Classify accounts using a follower-count threshold (for example, 100,000 followers).
    • Accounts below the threshold are treated as “normal”. When they post, background workers push their posts into followers’ precomputed lists (fan-out-on-write).
    • Accounts above the threshold are flagged as celebrities. Their posts are not pushed to follower lists; instead, they are fetched when followers read their feeds.
User read workflow (e.g., Alan opens his feed):
  1. Read Alan’s precomputed feed list from Redis. This contains posts from normal users that were pushed earlier.
  2. Fetch the most recent posts from the celebrity accounts Alan follows directly from a posts cache or database.
  3. Merge the two streams (precomputed posts + freshly fetched celebrity posts), sort by timestamp, and return the top N items (for example, 50).
This hybrid design avoids writing each celebrity post into millions of follower lists while keeping feed reads fast for the majority of users. A small celebrity flag in the users table (derived from follower count) indicates whether a post should be pushed to followers or pulled at read time.
A dark-themed architecture diagram titled "The Hybrid" illustrating a social feed system. It shows Redis feed and post caches, an app server, database tables (users, follows, posts, outbox) and a background worker/queue flow.
In short: normal accounts get pushed; celebrity accounts get pulled. This trade-off reduces wasted writes from celebrity posts while maintaining low-latency reads for most users.
Choosing the follower threshold is a trade-off: set it too low and you’ll increase read-time work; set it too high and you’ll incur expensive write amplification. Monitor system metrics (write throughput, read latency, storage costs) and adjust the threshold based on traffic and cost.

​
Comparison: fan-out strategies

​
Key terms and references

  • Fan-out-on-read: build the feed when the user reads it (read-time fetch-and-merge).
  • Fan-out-on-write: precompute the feed when a post is written (push-to-followers).
  • Celebrity flag: a boolean or enum in the user profile that indicates “pull at read time” semantics for that account.
Further reading and references:
  • Redis — https://redis.io/ (common store for precomputed feed lists and post caches)
  • System design guides on social feed generation and trade-offs
I introduced these terms after the explanation intentionally so the concepts would be clear in context.

Watch Video