The Hybrid Approach

In one line: the hybrid is the standard answer to the standard question, and the reason it works is not "a bit of each" — it is a property of the follower distribution.

The scheme

To balance the trade-offs, we categorize users based on follower count:

• Push-based (standard users): users with a few hundred or thousand followers. Their posts are pushed to followers' timelines immediately.
• Pull-based (celebrities): users with hundreds of thousands or millions of followers. Their posts are not pushed. Instead, followers fetch these posts on-demand when loading their timeline.

The timeline service aggregates data by pulling from celebrity accounts and reading the pre-pushed feed for standard accounts.

The hybrid is cheap because celebrities are rare — not because the strategies average out

The categorization looks like a compromise. It is not, and the reason is arithmetic.

Take a user following 250 accounts, per the chapter's own follower assumption. How many of those are celebrities with hundreds of thousands of followers? A handful — perhaps 5 to 10.

So the read-time merge is:

Pre-pushed feed        1 lookup   (240 ordinary accounts, already merged)
Celebrity accounts    ~10 lookups (fetched fresh)
                      -----------
Total                 ~11 operations, not 250

Eleven lookups, not two hundred and fifty. That is cheap enough to sit inside a feed request.

Meanwhile on the write side, the accounts that were generating hundreds of millions of writes each — Ronaldo, Dior, Gucci — stop fanning out entirely. And because follower counts follow a power law, those few accounts were responsible for a large share of total fan-out volume.

Removing the top of a power law removes most of the mass. That is the whole trick: you exclude a tiny number of accounts from push and eliminate a large fraction of the write load, while adding a tiny number of lookups to each read.

Each strategy is applied to the population where its dominant cost is smallest — and it works because the distribution is skewed, which is the same property that broke push in the first place.

Where do you draw the line? The design gives a range, not a rule

The categorization is "a few hundred or thousand" versus "hundreds of thousands or millions." That leaves a wide gap unaddressed — what about an account with 50,000 followers?

Both directions cost something:

Threshold too low — too many accounts classified as celebrities, so every read's merge grows. At some point you are doing pull for everyone.

Threshold too high — accounts with a million followers still fan out, producing exactly the bursts push was meant to avoid.

A better rule than raw follower count is expected cost:

Push when:  followers x P(follower reads soon)  <  cost of a read-time merge

That captures something follower count alone misses: an account with a million dormant followers should be pulled, while a smaller account with highly engaged followers should be pushed. Follower count is a proxy for cost, and a poor one when engagement varies.

A second refinement the design hints at in the pull section — "pre-generating timelines offline for active users" — is the reader-side hybrid:

By AUTHOR:  push ordinary accounts, pull celebrities
By READER:  precompute for active users, generate on demand for lapsed ones

With 1 billion total users and 500 million daily active, half the user base is not worth precomputing for on any given day. That is the larger of the two savings, and this chapter mentions it only in passing.

Why the merge is nearly free in practice

A concern worth addressing: doesn't the hybrid mean every read now does work, giving back push's main advantage?

Not really, for two reasons.

The merge is small. Eleven operations, as above, and the ten celebrity fetches are highly cacheable — a celebrity's recent posts are requested by millions of followers, so cache hit rates are excellent. The same skew that makes celebrities expensive to push makes them cheap to cache.

The read path is not otherwise empty. Even a purely pushed timeline needs hydration — Lesson 6 stores post metadata separately from media, and the timeline itself holds links rather than content. So there is already an assembly step; the celebrity merge joins it.

That second point is why the hybrid is standard in feed systems specifically. If a read path already has an assembly stage, adding a pull component to it is marginal work.

The design's own question, answered properly

Why is a hybrid approach better than purely push-based or pull-based timelines?

The complete answer has three parts, and most answers give only the first.

Because each pure approach fails at one end of the follower distribution. Push fails on high follower counts — 400 million writes per post. Pull fails on low posting rates — 90% of queries return nothing, repeated on every app open.

Because the failures are at opposite ends. Push's cost grows with followers; pull's grows with reads. So routing by follower count sends each account to the strategy whose cost is bounded for it.

Because the distribution makes the split cheap. Celebrities are rare, so few accounts move to pull and the read-time merge stays small — while those few accounts carried most of the write load, so removing them saves a lot.

The hybrid is not a compromise between two mediocre options; it is a routing decision that exploits a skewed distribution. Saying that is the difference between naming the answer and understanding it.

Next: where timelines are stored, and content that deletes itself.