Pull and Push

In one line: this is the chapter that covers fan-out from the design rather than around it. The two failure arguments here are both sharp, and the second one comes with a name attached.

The pull approach

This approach is known as "fan-out on load." When a user opens Instagram, the system generates the user's timeline on the spot. The service retrieves the accounts the user follows, fetches their recent posts, and aggregates them into a timeline for display.

Drawback: This creates high latency because the timeline is generated on-demand every time the app opens. We can mitigate this by pre-generating timelines offline for active users.

The design's own critique is better than its stated drawback

The stated drawback is latency. The design's Q&A gives a sharper one:

Instagram operates as a read-heavy system. Many users do not create posts and primarily consume content. As a result, many requests to fetch recent posts from followed accounts return no new content.

That is a genuinely good observation and it is not about latency at all — it is about wasted work.

Under pull, opening the app means querying every followed account for recent posts. But most accounts have posted nothing since you last looked. So the majority of those queries return empty, and you paid for them anyway.

Quantify it with the chapter's own numbers. If you follow 250 accounts and 95 million posts a day are spread across a billion users, the average account posts roughly once every ten days. So on any given app open:

250 followed accounts queried
~25 have posted since yesterday
~225 queries return NOTHING

Ninety percent of the work is wasted, and it is repeated every time the app opens.

That is a stronger argument than latency because latency can be mitigated — the design suggests pre-generating for active users, which is exactly the reader-side hybrid the newsfeed chapter identified. Wasted queries cannot be mitigated within pull; they are intrinsic to asking rather than being told.

Pull asks everyone whether anything happened. Push tells you when something did. In a system where most sources are usually silent, being told is enormously cheaper.

The names an interviewer will use

This chapter says pull and push. The interview vocabulary is usually fan-out on read and fan-out on write, and they are the same two things:

Use both names at least once so it is clear you know the standard terminology. The two failure modes are mirror images — read amplification on one side, write amplification on the other — and the hybrid exists because each is intolerable at a different end of the follower distribution.

The push approach

Also known as "fan-out on write." When a user creates a post, the system distributes it to the timelines of all followers. Follower timelines are precomputed at write time.

Benefit: Read latency is minimal because the data is ready when the user opens the app. It also eliminates wasted read requests for users who haven't posted recently.

The stated benefit names both wins, including the one pull's critique implied

Notice the second half: "eliminates wasted read requests for users who haven't posted recently."

That is the direct answer to the pull critique. Under push, a silent account generates no work at all — no queries, no empty results. Work happens only when something actually happens.

So push wins twice:

Push amortizes work across all future reads; pull repeats it on every read. With users opening the app many times a day, that ratio is large.

And then Ronaldo — 400 million followers, one post

The design's Q&A gives the failure case with a name:

Consider an account that belongs to a celebrity, like Cristiano Ronaldo, who has over 400 million followers. So if he posts a photo or a video, we will push the links to 400 million+ users, which is inefficient.

Work through what that means:

ONE post -> 400,000,000 timeline writes
At 1 million writes/second -> 400 SECONDS before the last follower sees it

Nearly seven minutes for a single post to finish propagating, during which the fan-out system is doing nothing else useful.

Three distinct failures, all from one event:

Latency. Followers at the end of the queue see the post minutes after followers at the front. For a platform where engagement is highest in the first minutes, that is a product problem, not just an engineering one.

Burst. This load is not steady-state — it arrives all at once when a large account posts, and several may post together. No steady-state capacity plan covers it.

Waste. Most of those 400 million followers will not open the app today. You have written to hundreds of millions of timelines nobody will read.

And note why an account can reach 400 million followers at all: Lesson 1's observation that following is unidirectional. A mutual-friendship model has a consent brake on both sides; one-way following has none. The celebrity problem is a consequence of the follow model, not an accident of fame.

Push costs O(followers) per post, and in a power-law graph the tail of that distribution is unbounded.

Both approaches are correct — the question is for whom

It is tempting to read this as "pull is bad, push is better, but push has a flaw." That is not the shape.

Pull is immune to follower count: Ronaldo posting costs exactly one write under pull, and the read cost is borne only by followers who actually open the app.

Push is immune to read frequency: a user refreshing fifty times a day costs fifty cache reads rather than fifty 250-way merges.

Each strategy is optimal in the regime where the other's cost explodes. That is what makes the hybrid in the next lesson a genuine solution rather than a compromise — you are not splitting a difference, you are routing each case to the approach that handles it well.

Next: routing each case to the approach that handles it.