1. Requirements & Estimation
Functional:
- A creator uploads a video; the platform processes and
publishes it
- A viewer watches a video, with quality that adapts to
their network conditions
- Views are heavily skewed: a small fraction of videos get
most of the views (a "long tail" distribution)
Non-functional:
- Scale: 500,000 uploads/day, 500M video views/day
- Upload size: average 500MB (varies widely)
- Playback must start within ~2 seconds of pressing play
Estimation:
Views: 500,000,000 / 86,400s ≈ 5,800 views/second average
peak (evening concentration) ≈ 5,800 * 4 ≈ 23,000/sec
Uploads: 500,000 / 86,400s ≈ 6 uploads/second average
-- MUCH lower volume than views, and NOT
latency-sensitive the way playback is (Section 2)
Views-to-uploads ratio: roughly 1,000:1 -- the system is
overwhelmingly a READ-heavy, playback-serving system, with
upload/processing as a comparatively rare, background-work path
That 1,000:1 ratio is the number that shapes the rest of this design: uploads can afford to be processed asynchronously, slowly, and expensively relative to views, because they're rare — but the playback path, which handles 23,000 requests/second at peak, needs to be fast, cheap per-request, and served from infrastructure that scales far beyond what any single origin server could handle directly.
2. Deep Dive: The Transcoding Pipeline
A video upload isn't stored and served as-is — it's transcoded into multiple resolutions and formats, which is genuinely slow, CPU-intensive work, entirely unsuited to happening synchronously while a creator waits.
[Creator] --uploads raw video--> [Upload Service]
|
stores raw file (Week 21's chunking
for the large upload itself)
|
publishes a "process this video"
job --> [Queue] (Week 8)
|
[Transcoding Worker Pool]
-- pulls jobs, transcodes the raw
video into multiple resolutions
(1080p, 720p, 480p, 360p) and
formats, in parallel across many
workers
|
writes each rendition to [Object
Storage] (Week 21), tagged by
resolution
|
on completion --> updates video
status to PUBLISHED, notifies creator
This is Week 8's queue pattern applied precisely to its strength: transcoding a single video can take minutes, and decoupling "accept the upload" from "process it" means the Upload Service returns quickly (the creator isn't stuck waiting), while a separately-scaled worker pool absorbs the actual processing load, sized independently from upload traffic. A large backlog during a traffic spike (many creators uploading at once) grows the queue rather than timing out uploads or overwhelming a synchronous processing path.
It might seem wasteful to transcode into resolutions a video may never be watched at (a video with 10 views doesn't need to have been pre-rendered at every quality level) — but transcoding on-demand, at the moment a viewer requests it, would add real latency to Section 1's 2-second playback-start target. Pre-transcoding trades upfront processing cost (paid once, for a rare event) for consistently fast playback (paid on every view, the far more frequent event) — the same amortization logic Week 19's precomputed autocomplete trie relied on.
3. Deep Dive: Adaptive Bitrate Streaming
A viewer's network conditions change mid-playback — they might start on WiFi and switch to cellular, or their connection might simply get congested. Adaptive bitrate streaming lets playback quality adjust in real time, without the video stopping to rebuffer at length.
Section 2's transcoding produces the SAME video, chopped into
short segments (~2-10 seconds each), at EVERY resolution:
1080p: [seg1][seg2][seg3][seg4]...
720p: [seg1][seg2][seg3][seg4]...
480p: [seg1][seg2][seg3][seg4]...
A manifest file lists all available quality levels and their
segment URLs. The VIDEO PLAYER (client-side) continuously
measures its own download speed and:
- downloading fast, no buffering issues --> requests the
NEXT segment at a HIGHER resolution
- download speed dropping, buffer getting low --> requests
the next segment at a LOWER resolution
Each segment is requested independently, so quality can change
between segments without restarting playback -- this is why a
video visibly "gets blurry" temporarily on a bad connection
instead of stopping entirely.
The key architectural point: the server does no adaptive logic at all — it just serves whichever segment/quality the player asks for. All the intelligence (measuring bandwidth, deciding when to switch quality) lives in the client player. This keeps the server side simple and stateless per request — serving a video segment is just Week 21-style object storage, retrieving a chunk by key, with no per-viewer adaptive state to track server-side.
4. Deep Dive: Storage & CDN Tiering for a Long Tail
Section 1 noted views follow a long-tail distribution: a small number of videos are watched constantly, and a huge number are watched rarely. Serving both kinds of video the same way is both slow (for popular videos, if not cached well) and wasteful (for rare videos, if kept unnecessarily "hot").
Popular video (millions of views):
--> segments cached aggressively across many CDN edge
locations (Week 2) -- most requests never reach origin
storage at all
--> stored with REPLICATION (Week 21) for fast, simple
recovery, since it's accessed constantly
Long-tail video (a handful of views ever):
--> rarely cached at the CDN edge -- not worth the cache
space for something requested a few times total
--> stored with ERASURE CODING (Week 21) for lower storage
cost, since access is rare enough that erasure coding's
slower reconstruction-on-recovery cost is rarely paid
A video's "temperature" isn't fixed -- yesterday's rare video
can suddenly go viral. Tiering has to be dynamic, monitored
by view-rate metrics (Week 17), promoting/demoting a video's
storage strategy as its actual access pattern changes.
This is Week 21's replication-vs-erasure-coding tradeoff, applied deliberately by access frequency rather than uniformly across all data — exactly the kind of per-workload tuning Week 21's callout flagged as the stronger answer over a single blanket policy. Combined with Week 2's CDN caching, the overwhelming majority of the 23,000 views/second from Section 1 are served from cache at the network edge, nowhere near origin storage or the transcoding pipeline at all — those two systems exist almost entirely to serve the comparatively rare cache-miss case.
5. Hands-on Exercise
Handle a video suddenly going viral
A video uploaded a month ago, with only a few hundred total views, is suddenly linked from a major news site and starts getting 50,000 views/hour.
Requirements:
- Given Section 4's tiering, describe this video's likely current storage state (hot or cold) and what needs to change now that it's viral.
- Explain, using Week 17's observability concepts, what metric would actually detect this spike is happening, and how quickly it would realistically be noticed.
- Decide whether "promoting" this video to hot storage should happen automatically or require a manual trigger, and justify against how often this scenario occurs versus how costly a delay is.
- Explain what happens to viewers in the window between the traffic spike starting and the video being fully promoted to aggressive CDN caching — is playback degraded, and if so how, referencing Section 3.
- State whether this scenario changes anything about Section 2's transcoding pipeline, or whether transcoding is unaffected since it already happened at upload time.
For requirement 5: transcoding is a one-time, upload-time cost (Section 2's callout) — the multiple resolutions already exist regardless of view count. A viral spike is purely a serving/caching problem, not a re-processing problem, which is itself worth stating explicitly as a reason this design separates the two concerns.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why is transcoding done asynchronously via a queue, rather than synchronously while the creator's upload request waits?
Why is transcoding done asynchronously via a queue, rather than synchronously while the creator's upload request waits?
Transcoding a video into multiple resolutions is slow, CPU-intensive work that can take minutes — forcing the creator's request to wait synchronously would create an unacceptably long, failure-prone upload experience. A queue decouples accepting the upload (fast) from processing it (slow), letting a separately-scaled worker pool handle the actual transcoding independently.
Q2
In adaptive bitrate streaming, why does the server not need to track any per-viewer adaptive state?
In adaptive bitrate streaming, why does the server not need to track any per-viewer adaptive state?
All the adaptive logic — measuring bandwidth and deciding which quality to request next — lives in the client player, not the server. The server just serves whichever specific segment the client asks for, a simple, stateless retrieval, which is why serving a segment is architecturally no different from any other object-storage lookup.
Q3
Why does a rarely-viewed video get stored with erasure coding while a hugely popular video gets stored with replication?
Why does a rarely-viewed video get stored with erasure coding while a hugely popular video gets stored with replication?
Erasure coding's lower storage cost comes with a real recovery-time computation cost, which is rarely paid for a video accessed only occasionally. A hugely popular video is accessed constantly, so replication's simple, fast direct-copy recovery matters more there than the storage savings erasure coding would offer — matching each storage strategy to how the data is actually accessed.
Q4
Why does aggressive CDN caching for popular videos matter more to overall system load than the transcoding pipeline's efficiency?
Why does aggressive CDN caching for popular videos matter more to overall system load than the transcoding pipeline's efficiency?
Views outnumber uploads roughly 1,000:1 in this system's estimation, so the playback path handles vastly more traffic than the processing path ever will. When CDN caching successfully serves most view requests from the edge, the overwhelming majority of that dominant traffic never reaches origin infrastructure at all — making cache effectiveness the primary lever on total system load, far more than transcoding pipeline efficiency.