The Finalized Design

In one line: one routing decision here is unlike anything in the previous chapters, and Lesson 3's egress figure is the reason.

The assembled architecture

We integrate a CDN to serve static media like images and videos. This ensures high availability and low latency for millions of concurrent users.

The load balancer routes read requests to the nearest CDN edge server. If the content is not found, the request forwards to the Read Application Server.

The CDN is in front of the application tier, not beside it — and that inverts the usual flow

Every other design in this module treats the CDN as a side path: requests go to application servers, which serve media from a CDN or reference it. Here the ordering is reversed.

USUAL:      client -> LB -> app servers -> (CDN for media)
INSTAGRAM:  client -> LB -> CDN -> (app servers ON MISS)

The CDN is the default destination for reads. Application servers are the fallback.

Lesson 3 explains why: 50.28 Tb/s of egress. At that volume, serving from origin is not slow — it is arithmetically impossible. No practical application-server fleet has terabits of egress, so the only viable architecture is one where the origin is rarely touched.

Three consequences follow.

The cache hit rate is a capacity constraint, not an optimization. If the CDN hit rate drops from 95% to 90%, origin traffic doubles. In most systems a cache miss costs latency; here it costs capacity you do not have.

Media must be immutable. Edge caching only works if content does not change under you. Which is why media is written once to blob storage and referenced by an immutable path — Lesson 6's photoPath — rather than being mutable.

Personalized content still cannot be edge-cached. The feed itself is per-user, so what the CDN serves is the media the feed references, not the feed. That is the same conclusion the Twitter and newsfeed chapters reached, and it means the read application server still handles every feed request — just not the bytes.

When egress reaches tens of terabits per second, the CDN stops being a component and becomes the read path.

Sharded counters appear only in an answer, and they are load-bearing

How can we count millions of interactions (like or view) on a celebrity post?

We can use sharded counters. Each counter has several shards distributed across various edge servers to reduce load on the application server and latency. Users nearest to the edge server get the updated count more frequently than those in distant regions.

The mechanism is that building block's: a single counter row is one lock, so a viral post's simultaneous likes all contend. Key-based partitioning cannot help when the hot spot is a single key — you split the key itself into shards and sum on read.

What is distinctive here is the placement: shards live "across various edge servers," so a like from Tokyo increments a Tokyo shard. The write never crosses an ocean.

And the design is honest about the cost: "users nearest to the edge server get the updated count more frequently than those in distant regions." The displayed count is eventually consistent and regionally divergent — which is fine, because nobody can distinguish 4,201,338 likes from 4,201,502.

Two things worth flagging.

This component is absent from the block list. Lesson 4 noted the omission; here is where it becomes load-bearing.

It is on more paths than the feed. Lesson 2 established that search results are "ranked by reach (likes and views)" — so the counters are also the search ranking signal, which raises their availability requirements beyond feed decoration.

What is still missing from the final picture

Four components the design needs and the final diagram does not show.

Transcoding. Lesson 7's point — 35 million videos a day must be converted to multiple resolutions before the CDN can serve them adaptively. It is plausibly the largest compute cost in the system.

A search index. Lesson 4 and Lesson 7 both flagged it. "Search by captions and location, ranked by reach" is not a database read.

The counter service. Present in the Q&A above, absent from every diagram.

Monitoring. No component observes system health, which the newsfeed chapter at least included in its final diagram.

The first is the most consequential. A media platform whose architecture diagram omits the pipeline that makes media servable has left out the thing that distinguishes it from a text platform.

Tracing a read through the finished design

Worth walking end to end, because the ordering is unusual:

1. User opens the app
2. LB routes the feed request        -> CDN edge
3. Feed is PER-USER, so CDN misses   -> read application server
4. Read server fetches the timeline  -> KV store (Lesson 10)
5. Timeline is a list of LINKS       -> hydrate metadata from cache/DB
6. Engagement counts                 -> sharded counters at the edge
7. Response: metadata + media URLs
8. Client requests media URLs        -> CDN edge, HIT
9. Lazy loading: only as the user scrolls (Lesson 7)

Steps 2–3 look wasteful — routing a personalized request to a CDN that will always miss. In practice the edge is doing useful work anyway: TLS termination, connection reuse, and routing over the CDN provider's backbone rather than the public internet, which is often faster to the origin than a direct path.

But the important observation is step 8. That is where the 50 Tb/s lives, and it is served entirely from the edge without touching a single application server.

The request that matters for correctness and the request that matters for capacity are different requests. The feed request is small, personalized, and cannot be cached; the media requests are large, shared, and cache perfectly. Separating them is the whole architecture.

The board an interviewer wants to see

Worth drawing this as one picture with the schema annotated directly on it, including partition and sort keys — that is what turns an architecture sketch into something an interviewer can check.

Three things this makes visible that a prose description does not. The media path bypasses the application tier entirely in both directions — presigned upload out, CDN download back. The fan-out queue sits between posting and feed writes, which is what makes a post return immediately while millions of feed inserts happen behind it. And the key design is on the page: partitioning posts by userId with a time-ordered sort key is what makes "recent posts by this user" a single efficient range read.

Next: checking the design against its requirements.