Worked Example: Designing a Video Platform (like YouTube)

The prompt sounds simple: users upload videos, other users watch them. What makes this one of the toughest "classic" questions is the sheer asymmetry between the two paths. Uploads happen a few hundred times a minute; playback happens a billion times a day. A design that treats those two paths as symmetric will fail on the read side long before the write side even notices load.

• -Functional: a user uploads a video; the platform makes it available for playback at multiple quality levels; viewers stream it with the player adapting quality to their current bandwidth.
• -Out of scope (say this out loud): live streaming, recommendation ranking, monetization/ads. Assume video-on-demand only.
• -Non-functional: playback must start within a couple of seconds anywhere in the world, and must not stall mid-stream on a shaky connection. Upload processing can take minutes; nobody expects a freshly uploaded video to be watchable instantly.

Assume 500 hours of video uploaded per minute (a real, often-quoted YouTube figure) at roughly 500MB per video and an average video length of about an hour, and 1 billion views per day averaging about 10MB of actual bytes streamed per view once adaptive bitrate and partial watch-time are accounted for.

Instead of serving one fixed-quality file, the platform splits each video into short segments (a few seconds each) and encodes every segment at several resolutions and bitrates (360p, 720p, 1080p, 4K). A manifest file lists every available segment at every quality. The player continuously measures the viewer's actual bandwidth and, segment by segment, requests whichever quality it can sustain right now, switching up or down without ever restarting playback.

• -Pre-transcode everything on upload: every rendition exists the moment the upload finishes processing, so first playback at any quality is instant. Costly, since most uploaded videos get very few views and most of those renditions are never requested.
• -Transcode on demand: only generate a rendition (especially expensive ones like 4K) the first time a viewer actually requests it, then cache the result. Saves storage on the long tail of rarely watched videos, at the cost of a short delay the first time someone asks for an unusual quality.

• -Storage cost vs. instant availability: storing every rendition of every upload multiplies total storage 4-6x. The lazy-transcode approach above trades a small first-request delay for real savings, since view popularity is extremely skewed toward a small fraction of uploads.
• -Transcoding backlog: the message queue absorbs upload spikes so the upload API keeps accepting new files even if workers fall behind. A backed-up queue means new videos take longer to become watchable; it does not mean uploads fail or get dropped.
• -Cold cache on a viral video: a brand-new video has no CDN cache history, so its first wave of viewers can all hit origin storage simultaneously. Pre-warming the CDN for promoted or high-profile uploads, or fronting the origin with a shield cache layer, keeps that initial spike from overwhelming Blob Storage directly.