Media-First Social

In one line: Twitter and the newsfeed chapter were text systems with media attached. Here the media is the product, and that inversion changes which numbers matter and which components carry the weight.

The product

Instagram supports roughly 1 billion users who share about 95 million posts per day. The system is read-heavy because users browse feeds far more often than they create posts. Design priorities include storage efficiency and low-latency feed retrieval.

The inversion: text was the payload, now it is the label

Put the three social chapters side by side and the shift is stark.

Lesson 3 will show that 96.7% of Instagram's storage is video — the captions and metadata are a rounding error, and that is a stronger version of the pattern Twitter showed at 88%.

Two consequences that shape everything after.

The blob store and CDN stop being supporting components. In Twitter they served the attachments; here they serve the product. The finalized design in Lesson 11 routes reads to the CDN first, falling back to application servers only on a miss — an ordering no previous chapter used.

Metadata becomes genuinely small. Lesson 6's schema totals a bit over a terabyte for a billion users' worth of relationships and post metadata. That fits comfortably in a relational database, which is why this chapter — unlike Twitter's — can reasonably answer "just use SQL."

When the media is the product, the metadata system gets easier and the delivery system gets harder. That trade runs through the whole chapter.

What this chapter does well

This is the chapter that finally covers fan-out

Worth flagging up front, because the previous two chapters left a gap.

that building block (Twitter) deferred timeline generation to the newsfeed chapter. that building block (Newsfeed) mentioned fan-out in six words — "using one of the fan-out approaches" — and never explained it.

This chapter covers it properly. Lessons 8 and 9 follow the design through the pull approach, the push approach, and the hybrid, with a concrete failure case: an account with 400 million followers, where one post means 400 million timeline writes.

So this is the chapter where the canonical social-feed mechanism is actually taught from the design rather than authored to fill a hole. If you read only one treatment of fan-out in this module, the material in Lessons 8 and 9 is the one the course's own sources support.

And where it goes wrong: one lesson, three server counts

Lesson 3 works through this, but it is worth knowing the shape now.

The estimation lesson produces three different answers for the same question:

2       servers  (116K RPS / 64,000 per server)   <- uniform distribution
8,000   servers  (500M "RPS" / 64,000)            <- DAU-as-RPS, labelled "peak"
15      servers  (from the interactive table)     <- uses 8,000 RPS per server

The prose and the table disagree about server capacity by 8×, and the "peak" figure is 4,320× the computed average — it is the daily-active-user count with a different label.

To the chapter's credit, it is the only one in this module to compute the uniform case at all and to frame the two figures as lower and upper bounds. That framing is right; one of the bounds is not.

The five features

Unidirectional following is a small detail with real consequences

The design is explicit: "Instagram uses a unidirectional model: if User A follows User B, User B does not automatically follow User A."

That distinguishes it from a friendship graph, and it matters in three places:

Follower counts are unbounded. In a mutual-friendship model, both sides must consent, which naturally caps the degree — nobody accepts 400 million friend requests. One-way following has no such brake, which is exactly how an account reaches 400 million followers and breaks push fan-out.

Two indexes are needed. Who does A follow (for pull) and who follows B (for push) are different queries over the same table, with wildly different result sizes.

The graph is skewed by construction. A symmetric graph tends toward a bounded degree distribution; an asymmetric one produces a power law. The celebrity problem is a consequence of the follow model, not an accident of popularity.

The whole chapter turns on where you pay: a post is written once and read enormously, so precomputing at write time is almost always the right trade. The exception — an account with tens of millions of followers — is what makes the design interesting rather than obvious.

Next: the requirements, and a contradiction between two of them.