Media & storage: multiple-choice review
Multiple-choice synthesis across the media-storage cases: the control-path/data-path split, transcoding ladders and adaptive bitrate, content-addressed chunking and delta sync, erasure coding for durability, and per-user partitioning for email.
Six questions that cut across the whole unit. Each is a decision you make at a whiteboard designing a media system — keeping bytes off the app path, choosing a redundancy scheme, picking a partition key — not a definition to recite.
Confirm you can keep large bytes off the app servers, justify a transcoding ladder, reason about content-addressed chunking and delta sync, choose erasure coding vs replication on cost, partition email by user, and recognize where a number can safely be approximate.
Across YouTube, Drive, object storage, and email, what single principle governs how large bytes move?
Why does a video platform transcode one upload into a ladder of renditions cut into short segments with a manifest?
A user edits one paragraph of a 200 MB file in Drive. What makes the sync efficient, and what extra benefit comes free?
An S3-like store must hit ~11 nines of durability for exabytes of cold data at minimum storage cost. Which scheme, and why?
Designing Gmail-scale email, what is the natural partition key, and why does it make the system scale cleanly?
A video's view count gets hundreds of thousands of increments per second. Which design respects the eventual-consistency lesson?
- 01What's the recurring rule for moving large bytes, and why?
- 02When do you erasure-code vs replicate, and why partition email by user?
The through-line across all four cases is that media systems are shaped before you build them. Keep large bytes off the app server’s data path — upload direct to object storage, reference by key, serve from a CDN/data plane — so the API stays on the control path. Transcode one upload into a ladder of segmented renditions so adaptive bitrate can match each viewer’s changing network. Content-addressed chunking gives delta sync (move only changed chunks) and dedup (identical chunks stored once) from one mechanism. Erasure coding (10+4 ≈ 1.4× overhead) hits 11 nines far cheaper than 3× replication for cold data, while you still replicate small hot objects. Partition email by user because mailboxes have no cross-user joins on the hot path. And accept eventual consistency where humans can’t tell — a viral view counter is logged and aggregated, never synchronously incremented on one hot row. Get the structure right and the rest is detail; get it wrong and no tuning saves you.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.