Design a Video Streaming Platform

Prompt

"Design YouTube. Users upload videos, other users watch them. Focus on upload, processing, and playback; skip comments and recommendations unless we get there."

Clarifying questions

• Scale? Roughly a billion daily active viewers and hundreds of hours of video uploaded every minute. Use round numbers.
• Live streaming or only on-demand? On-demand only. Live is a follow-up.
• Max upload size and length? Tens of gigabytes and up to 12 hours; assume the typical upload is 10 minutes and a few hundred megabytes.
• Which devices? Web, mobile, and TV, so multiple resolutions and codecs are required.
• Does playback need to start before the whole file is ready? Yes for viewers: adaptive bitrate streaming from the first segment. Uploaders can wait minutes for processing.
• Do we need view counts? Yes, approximately correct within a minute is fine.
• Monetisation, DRM? Out of scope.
• Availability target for playback? As close to always-on as possible; upload can degrade.

Requirements

Functional

• Upload a video with title and metadata; report processing status.
• Transcode into multiple resolutions and codecs, generate thumbnails.
• Stream via adaptive bitrate to any device; seek anywhere in the video.
• Search by title (basic) and show a video page with metadata and view count.

Non-functional

• Playback start under 2 s and no rebuffering for the median viewer.
• Durable storage of the original upload; losing a creator's video is unacceptable.
• Processing latency of minutes is fine; playback availability must not depend on the processing system being healthy.

Back-of-envelope

• Uploads: assume 500 hours of video per minute → 500 × 1,440 = 720,000 hours/day. At 10 minutes per video that is about 4.3M videos/day, or about 50 uploads/s. Upload QPS is trivial; upload bytes are not.
• Upload bytes: 720,000 hours/day × 3,600 s × a typical 5 Mbps source bitrate ≈ 720,000 × 3,600 × 0.625 MB/s ≈ 1.6 PB/day of raw uploads. Per year, about 600 PB of originals.
• Transcoded outputs: storing 5 renditions (240p through 1080p, plus 4K for a subset) roughly doubles the bytes. Budget on the order of 1.2 EB/year total, with tiered storage moving cold renditions to cheaper media.
• Playback: 1 billion DAU watching an average of 30 minutes at an average delivered bitrate of 2 Mbps → 1e9 × 1,800 s × 0.25 MB/s = 450 PB/day, or about 5.2 TB/s average egress and perhaps 15 TB/s at peak. This single number justifies the whole CDN discussion: origin cannot serve this; edge caches must.
• Concurrent streams at peak: if a third of DAU watch at the same evening peak, ~300M concurrent streams. Each fetches a 4-second segment roughly every 4 s → 75M segment requests/s at the edge. Origin sees only cache misses, ideally under 1%.
• Metadata: 4.3M new videos/day × 365 × (say) 5 KB of metadata ≈ 8 TB/year. Small next to the video bytes; the metadata store is a scaling problem for read QPS, not size.
• Transcoding compute: 720,000 hours/day of input; if transcoding a minute of video into all renditions costs roughly 2 minutes of one core, that is 720,000 × 60 × 2 = 86.4M core-minutes/day ≈ 60,000 cores continuously. A real fleet, but it can run on preemptible capacity because it is off the critical path.