> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# News Feed The Celebrity Problem
> Describes a hybrid social feed design that pushes posts for normal users and pulls celebrity posts at read time to reduce write amplification while balancing read and write costs
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.
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
| Strategy | Pros | Cons | When to use |
| - | -: | - | - |
| Fan-out-on-write (push) | Low read latency; simple read logic | High write amplification for popular posters; cost of storage | Most users with typical follower counts |
| Fan-out-on-read (pull) | Low write amplification; efficient for celebrities | Higher read latency and compute at request time | Systems with few reads or many celebrity posts |
| Hybrid (push normal, pull celebrities) | Balances read/write costs; avoids celebrity write floods | More complex logic; needs thresholding and merging logic | Large-scale social systems with mix of normal and celebrity users |
## 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/](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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.