Upload, View, and Search

In one line: the read/write split here is the same move that building block made, justified by the same ratio — and this chapter states the justification more clearly than any before it.

The workflows

The read/write split is earned here, and the ratio is stated explicitly

Lesson 3 gave the number: a read-to-write ratio of 100:1, used directly to derive outgoing bandwidth as 100× incoming.

That is a much better justification than most chapters manage, because it is quantitative. Three consequences follow, and each shows up in the design:

They scale independently. Read servers outnumber write servers roughly 100:1. Traffic growth on the read side requires no write capacity at all.

They have different dependencies. The write path touches blob storage and the database. The read path touches the cache, the CDN, and the database — and per Lesson 11, mostly the CDN.

They fail differently. A read outage means users cannot browse — bad, and recoverable. A write outage means uploads fail, and per Lesson 2's durability requirement, a failed upload may mean a lost photo the user has no other copy of.

That third point argues for something the design does not mention: the write path should be more conservative than the read path, not merely smaller. Uploads should be acknowledged only after durable, replicated storage — which means the write path is slower by design, and that is correct.

When the read/write ratio exceeds roughly a hundred to one, reads and writes stop being two operations on one system and become two systems sharing a data model. Same conclusion that building block reached at a ratio in the millions.

Lazy loading is the client-side half of the CDN argument

"We implement lazy loading. This minimizes latency and bandwidth usage by only loading content as the user scrolls."

Easy to read as a front-end nicety. At Lesson 3's numbers it is a capacity decision.

A feed of 30 posts, eagerly loaded, means fetching 30 media items. If the user scrolls through five, 83% of that bandwidth was wasted — and at 50 Tb/s of egress, waste is the dominant cost.

So lazy loading does three things:

Cuts egress proportionally to scroll depth. Users who scroll less cost less.

Improves time-to-first-render, since the first screen needs only its own items.

Composes with the thumbnail-and-link model from Lesson 5 — load a small preview eagerly, fetch full media only on engagement.

The Google Maps chapter made exactly this argument for map tiles: "fetch tiles for the viewport, not the route." Same principle, different medium.

Lazy loading and CDN caching are the same optimization applied at two ends of the wire — the CDN reduces the distance bytes travel, lazy loading reduces how many bytes travel at all. The second is strictly more effective, because bytes never sent cost nothing anywhere.

'The server stores the photo in blob storage' skips transcoding entirely

The upload flow is three steps: client sends, server stores, server acknowledges.

For 35 million videos a day, that is missing the expensive middle. Before a video can be served it must be:

• Transcoded into multiple resolutions and bitrates for adaptive streaming.
• Segmented into chunks for progressive delivery.
• Thumbnailed for the feed preview Lesson 5's design needs.
• Scanned for policy violations.

The YouTube chapter treated encoding as a first-class subsystem with its own pipeline. Here it is invisible, and it should not be — it is plausibly the largest compute cost in the system, and Lesson 3's estimate has no line for it either.

It also changes the acknowledgement semantics. If the upload is acknowledged after storing the original, the post exists but is not yet viewable. So there are two states:

UPLOADED   -> original stored durably, acknowledged to the user
PROCESSED  -> transcoded, thumbnailed, ready to appear in feeds

And the gap between them is why a freshly-posted video sometimes appears with a delay. Acknowledge on durability, publish on readiness — the same two-phase structure that building block used for payments and the newsfeed chapter for generation.

Search is described in one line and needs a component the design lacks

"When a client requests to view or search for a photo, the application server fetches the matching content from the database."

Fetching from the database works for a lookup by ID. It does not work for Lesson 2's actual requirement: "search based on captions and location," ranked by reach.

That needs an inverted index over caption text and hashtags, a geo index over locations, and a ranking pass over engagement counts. A LIKE '%keyword%' scan over 95 million posts a day is not a search implementation.

Lesson 4 flagged that the block list omits a search index. This is where the omission becomes concrete: the workflow describes search as a database read, and it cannot be one.

Worth raising, because it is a small sentence hiding a whole subsystem — the same subsystem that building block built on Lucene with a RAM-resident recent index.

Serving the original bytes to every viewer is the mistake to avoid. A feed thumbnail on a phone needs a tiny fraction of a full-resolution image, and sending the original wastes bandwidth on both ends for no visible benefit.

Dynamic media optimization means the CDN chooses a variant — resolution, format, compression — based on the requesting device and connection. The client asks for an image; the edge decides which one it actually gets.

Note the delivery path: media goes from the CDN straight to the client and never re-enters the application tier. That is what keeps a media-heavy product from scaling its API servers on bandwidth.

Next: the two pure timeline strategies.