Deploy: Edge Placement and Recommendations

In one line: this lesson answers the question Lesson 2's 12 Tbps posed — you cannot serve that from data centers, so content has to live inside the networks that carry it.

Three advantages

1. Users will be able to stream videos quickly.
2. There will be a reduced burden on the origin servers.
3. Internet service providers (ISPs) will have spare bandwidth.

The third advantage is the one that makes ISPs cooperate — and it is the whole business case

Reasons one and two benefit YouTube. Reason three benefits the ISP, and that is why this arrangement exists at all.

Without a cache inside the ISP's network, every view of a popular video traverses the ISP's expensive transit links to reach YouTube. With a cache, the first request pulls it in and every subsequent view is served locally — traffic that never crosses a paid interconnect.

So the ISP saves real money on transit, and YouTube gets its content one hop from users. Both sides win, which is what makes a commercial arrangement possible where a purely one-sided request would fail.

That is a genuinely important thing to understand about content delivery: you cannot put a cache in someone else's network unless it is worth their while. The technical design is straightforward; the reason it is deployable is economic.

The IXP fallback covers the case where no such arrangement exists — a neutral exchange point where many networks meet, so content sits close to several ISPs without being inside any of them. IXPs can also fill the ISP PoP caches, making them a second tier rather than only a fallback.

Splitting origin storage by popularity

This is the access-tier idea from object storage, applied to hardware

Two tiers, matched to access frequency: fast expensive media for the hot set, cheap dense media for the long tail.

That is exactly the hot/cool/archive reasoning from object storage, and it works here for the same reason — Lesson 1's long tail means most of the catalogue by count is almost none of the views. Putting all of it on flash would be enormously expensive for content nobody requests.

The distinction from the CDN is worth being clear about. CDNs and ISP caches hold the hot set near users. Flash-versus-storage is a split within origin, for everything the edge did not cache. So there are effectively three tiers by popularity:

very popular      -> ISP PoPs / IXPs / CDN   (nearest, smallest)
moderately popular-> flash servers at origin  (fast, medium)
unpopular         -> storage servers at origin(dense, cheap)

Latency rises as you go down, and that is correct — the latency of a video nobody watches does not matter.

Transfer content to ISPs during off-peak hours

When we transfer streaming content, it can result in the congestion of networks. That is why we have to transfer the content to ISPs in off-peak hours.

Filling an edge cache is itself a large data transfer, and doing it during peak viewing competes with the users you are trying to serve — you would congest the network in the act of trying to relieve it.

Off-peak transfer uses capacity that is otherwise idle, which is the same insight as distributed task scheduling's deferrable work filling the off-peak trough: capacity you have already paid for is free if you can shift work into it.

It also implies you must predict what to cache several hours ahead, since you are filling caches before demand arrives rather than reactively. Which is what makes the popularity prediction below load-bearing rather than a nicety.

Placement is a state, not a one-time decision, and it moves in both directions. Note the last transition: a major channel's upload is pushed straight to the edge on publish, because waiting for demand to be observed would miss the spike entirely.

Recommendations

YouTube recommends videos based on the user's profile — interests, view and search history, subscribed channels, related topics to already viewed content, and activities such as comments and likes.

Two phases:

Machine learning is employed in both phases.

Two stages exist because you cannot run an expensive model over millions of candidates

The funnel — millions → hundreds → dozens — is a standard architecture, and the reason is cost per item.

Candidate generation must be cheap enough to run against the entire catalogue, so it uses coarse, fast signals — collaborative filtering, embedding similarity, subscription lists. It optimizes for recall: do not miss anything good.

Ranking can afford a much richer model because it only sees hundreds of items. It optimizes for precision: order these correctly.

Running the ranking model over millions of videos per request would be computationally impossible; running only candidate generation would produce relevant-but-poorly-ordered results.

This is the identical structure to distributed search's retrieval then ranking, and to Lesson 5's search pipeline. Cheap filter, expensive rank is one of the most reusable patterns in large-scale systems.

Popular versus recommended

Recommendations are specific to users' profiles and interests, whereas popular content is recognized on a regional or global basis. It is possible to present popular content to the general audience.

Only popularity is cacheable — recommendations are per-user by definition

This distinction has a direct architectural consequence that is easy to miss.

Popular content is a property of the content, computed regionally or globally. It is the same for everyone in a region, so it can be computed once and — crucially — pushed to edge caches, which is exactly what this lesson's deployment does.

Recommendations are a property of the user. Two people in the same city get different lists, so there is nothing shared to cache and nothing to pre-position.

That is why edge placement is driven by popularity, not recommendations. You cannot pre-position content for a recommendation you have not computed for a user who has not arrived.

The two do interact: a video that gets recommended widely becomes popular, and then gets cached. So recommendations drive demand and popularity drives placement — with a lag, which is another reason placement must be predictive.

Approximating popularity

To approximate a formula, assume a threshold value which is the weighted sum of all considered factors:

Th_reg = Comments_wt x Comments_num
       + Likes_wt    x Likes_num
       + Links_wt    x Links_num
       + ...

Th_reg    = the number used to decide whether a video is viral in a specific region
*_wt      = the weight of that factor
*_num     = the count of that factor

The cumulative sum of each weight equals 1.

Different threshold levels can be considered for different regions. A video is globally popular if the sum of thresholds of different regions passes a global threshold value. YouTube may also put some videos directly in CDN depending on the channel used to upload.

How often should this be computed? Not on every click.

"Will the popularity calculation be made on each click, like, or comment?"

Calculation per click, like, or comment requires special infrastructure to perform calculations correctly and in real-time. This should be limited to the most popular channels — or a particular metric that triggers the computation every time it crosses a certain value. A good trigger is an increasing number of requests for a specific video in a shorter period.

Two mechanisms, and both are about spending computation where it matters:

Restrict by channel. Only compute continuously for channels likely to go viral — the same follower-count heuristic the sharded-counters pattern used for shard allocation.

Trigger on rate of change. Recompute when the request rate rises sharply, not on every event. That is the right signal, because virality is a derivative — a video going from 100 to 10,000 views an hour is the interesting event, not one with a permanently high total.

Note the escape hatch: putting videos directly in the CDN based on the uploading channel. A major channel's new upload will be popular, so you skip the detection entirely and pre-position it. Prediction where it is reliable, detection where it is not — the same pairing the sharded-counters pattern used for shard sizing.

Interview signal by level

Next: adapting to the client in real time.