Media & storage: free-recall review
Free-recall prompts across the media-storage cases. Reconstruct each design in your own words first — the bytes/metadata split, the transcoding pipeline, chunking and conflict resolution, durability via erasure coding, and email at scale — then reveal and compare.
Retrieval beats re-reading. For each prompt, reconstruct a full design from memory — the data flow, the split, the failure mode it avoids — before you open the model answer. The effort of rebuilding the architecture is what makes it stick.
Reconstruct each design without looking back: how YouTube’s write and read paths split, what transcoding produces and why, how Drive moves the fewest bytes and resolves conflicts, how an object store reaches eleven nines cheaply, and how email scales by partitioning everything per user.
- 01Reconstruct YouTube's two paths and the rule that governs both.
- 02Why does transcoding produce a ladder of segmented renditions plus a manifest?
- 03How does Drive move the fewest bytes, and how does it resolve conflicting edits without data loss?
- 04How does an S3-like store reach ~11 nines durability cheaply, and where does consistency live?
- 05How does Gmail-scale email scale, and name two heavy-byte and structured-state decisions.
If you could reconstruct each design from memory, you hold the unit’s spine. YouTube splits an async write path (direct-to-object-store upload, transcode into a segmented rendition ladder + manifest for adaptive bitrate) from a fast read path (viewer→CDN), keeping the API on the control path and making view counts eventually consistent. Drive moves the fewest bytes via content-addressed chunking (delta sync + dedup) and never overwrites — the version chain detects conflicts, resolved as conflicted copies. An object store reaches ~11 nines cheaply with erasure coding (10+4 ≈ 1.4× vs 3× replication) for cold data, keeps consistency in the metadata service, and uses multipart upload for huge objects. Email partitions everything by user, rejects spam at ingest, deduplicates attachments in object storage, serves search from a per-user inverted index, models labels as a many-to-many overlay, and syncs incrementally via a change log. The single thread: separate the heavy bytes (object storage, deduplicated, CDN-served) from the structured state (metadata, indexes, versions, change logs), and spend your consistency budget only where a human would notice.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.