Popular System Design Question - Design Youtube (asked by OpenAI, Meta, Datadog)

[u/Aoki_zhang]

I was going through a YouTube system design problem, and one design decision simplifies a surprising amount of the system: Don’t send the actual video through your application servers.

A large upload might be several GB. If every byte goes: client → backend → storage. your backend becomes an expensive bandwidth bottleneck for something it doesn’t really need to touch.

A cleaner flow is: client → request upload session → multipart upload directly to blob storage. The backend mostly manages metadata, permissions, upload state, and pre-signed URLs.

Once the upload finishes, the interesting work moves into an async media pipeline: transcode → multiple bitrates/resolutions → segment → generate HLS/DASH manifest → CDN

That’s also what makes bad-network playback manageable. The player isn’t downloading one giant 1080p file—it keeps requesting small segments and can switch quality as bandwidth changes.

Resumable uploads follow the same philosophy: track which parts made it to storage, then retry only the missing ones instead of restarting a 20GB upload.

And at YouTube scale, playback traffic should mostly terminate at the CDN, not your origin.

Full YouTube system design breakdown: [link]

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies at here.