Fan-Out & Feed Generation

Think about the Meta Post Privacy question: a user publishes a single post, and that post needs to show up in the feeds of every one of their followers. For someone with 500 followers, that's straightforward. But for a celebrity with 10 million followers? That single write must somehow become readable by 10 million people in their personalized feeds — fast. This is the fan-out problem, and it's one of the most important scaling challenges in social media, messaging, and notification systems.

The core tension is simple: do you pay the cost at write time or at read time? Each approach has clear trade-offs, and real systems like Twitter and Instagram use a clever combination of both.

Fan-Out on Write (Push Model)#

The fan-out-on-write approach precomputes every follower's feed at the moment a post is published. When a user creates a post, a fan-out service immediately writes a reference to that post into every follower's precomputed feed. Each follower's feed becomes a simple list — reading it is an O(1) fetch.

The cost is O(followers) writes per post. For a user with 1,000 followers, that's 1,000 writes — completely manageable. The massive advantage is that reads are instant: when someone opens their feed, you just fetch a pre-built list. No joins, no merging, no computation at read time.

This is the default strategy for most users in most systems. It works beautifully when follower counts are moderate (hundreds to tens of thousands). The write pipeline typically flows through a message queue like Kafka: the Post Service publishes a new-post event, fan-out workers consume it, look up the author's follower list, and append the post reference to each follower's feed in a store like Redis or DynamoDB.