System Design: How to Design YouTube

We will design a video-sharing service where creators upload media and viewers play it. This is a teaching architecture for a similar product, not a statement about YouTube’s production internals.

Assume 1,000 uploads per day averaging 200 MB and 100,000 daily playback sessions. An illustrative session transfers 100 MB on average. That implies 200 GB/day of raw uploads and 10 TB/day of viewer payload transfer in decimal units, before variants, replicas and overhead.

Multipart or resumable uploads can retry failed pieces instead of restarting the entire file. The system needs a stable upload identity, allowed size and type, integrity validation and an explicit completion step.

Keep source media in object storage and metadata in an appropriate database. Record upload state so a client can see whether it is incomplete, accepted for processing or rejected.

Clean up abandoned uploads and orphan objects under a retention policy. Storage permission and a successful first chunk do not mean a complete valid video exists.

Transcoding converts media into selected formats or bitrates. Different outputs can support different devices and network conditions. Generating more variants consumes processing and storage.

A queue can trigger processing after verified upload. Workers should record job identity and output status so retries do not silently publish inconsistent or duplicate results.

Validation and policy checks may be required before publication. Mark the video ready only after its required outputs and checks satisfy the contract. A failed worker needs a visible failure and retry path.

The local state machine starts Awaiting upload. Complete upload, then advance validation, transcoding and publication. Enable a failure at transcoding to see the state stop before readiness.

Disable the simulated failure and retry to return to processing, then advance to a ready state. The lab does not upload or transcode real files. It illustrates state transitions and does not model moderation, asynchronous timing or partial output cleanup.

Playback can fetch segments or files through delivery infrastructure such as a CDN. Adaptive playback can choose among available variants based on client capabilities and network conditions.

Measure start delay, stalls, errors and viewer geography. Peak concurrent viewing and transferred bytes matter separately from upload count. Cache hits can reduce origin work, while cold content still needs origin capacity.

Public and private videos need different access rules. Expiry, deletion and cache propagation should match the required user-visible behaviour. A valid object URL is not automatically permission for every viewer.

S3 multipart uploads are one managed storage option. AWS Elemental MediaConvert offers managed media processing. Sources checked 6 October 2026. Their contracts, quotas and charges need workload-specific evaluation.

Self-operated processing workers can offer configuration control but add scaling, upgrades and incident work. Managed processing reduces some infrastructure work while introducing service limits and commercial costs. A CDN needs its own transfer, cache and access evaluation.

Compare processing turnaround, failure recovery, output compatibility and full delivery cost with representative media. Do not infer universal uploads/s or viewers/s from a product name.

Use State to express readiness transitions, Asynchronous Request/Reply for processing status and Template Method only where a stable local stage sequence truly exists.

Separate durable upload, validation, processing and ready publication. Make failure and retry states honest and observable.

Estimate upload, storage, processing and viewer transfer independently. Evaluate delivery quality and access policy with the actual media and audience.