Design YouTube

A video is a few hundred bytes of metadata plus gigabytes of raw media. How do you store them?

1. Rejected. Store everything — metadata and the media blob — in one database.

   Gigabyte media blobs bloat a database, make queries slow, and waste its expensive indexed storage. Databases are for small structured queryable data, not opaque write-once files.

2. Rejected. Store both in object storage.

   Object storage is great for the giant media but terrible for the queryable facts (title, owner, status, search) you constantly look up. You need a database for those.

3. The call. Metadata in a DB, raw bytes in a Blob Store (S3-like).

   Tiny structured facts go in a queryable database; huge write-once media goes in cheap object storage. Watch requests read metadata first, then fetch bytes — splitting them is the foundation.

The raw upload is one giant file in one codec. A 3G phone and a 4K TV need different versions. How do you produce them?

1. Rejected. Transcode on the fly when each viewer requests a quality.

   Re-encoding per view is enormously expensive and slow — you’d redo the same work for every viewer. Encode once, up front, into all qualities and reuse.

2. The call. Async: queue an encode job; workers build an ABR ladder of segments.

   The upload service drops a job on a queue; a transcoder fleet re-encodes into 240p–4K, each chopped into small ~2–10s segments written back to blob, then marks the video ready. The player switches quality mid-stream from the precomputed ladder (HLS/DASH).

3. Rejected. Ask the uploader to provide every resolution.

   Creators upload one master file and can’t be expected to produce a full ABR ladder of segmented renditions. Encoding is the platform’s job, done asynchronously off the upload path.

Views dwarf uploads and viewers are everywhere. Streaming every segment from one origin would be slow and ruinous. Fix?

1. Rejected. Add more origin servers in your one region.

   More origin capacity in one place still pays a long round-trip to distant viewers and concentrates bandwidth cost. You need bytes physically close to users.

2. Rejected. Stream the whole video to the client up front to cache locally.

   Pre-downloading gigabytes wastes bandwidth (most of a video is never watched) and delays start. You want to stream small segments on demand from a nearby edge.

3. The call. Put a CDN in front; serve immutable segments from edges.

   The player pulls the manifest then segments from the nearest edge; the first regional viewer warms the cache, everyone after gets bytes from down the street. Immutable segments cache perfectly — the CDN offloads 95%+ of traffic. The CDN IS the read-scaling strategy.

Every upload becomes 5–6 renditions in many segments, and 500 hours arrive every minute. How do you store exabytes affordably?

1. The call. Tiered storage: replicate popular content, push the long tail to cold storage.

   A tiny fraction of videos drive most views — keep those replicated and ready; let the millions of near-zero-view uploads sit in cheap cold tiers, accepting a slower first byte if someone finally watches them.

2. Rejected. Keep every rendition replicated across all regions.

   Replicating everything everywhere is ruinously expensive when most videos are barely watched. Match storage cost to popularity — hot content hot, cold content cheap.

3. Rejected. Delete videos that haven’t been watched recently.

   Deleting creators’ uploads to save space is unacceptable — they expect permanence. The answer is cheaper cold storage for the long tail, not deletion.

The CDN handles bytes, but metadata reads, search and upload coordination still hit your services, and one server is a SPOF. How do you scale them?

1. Rejected. Vertically scale the one server handling everything.

   A bigger box has a ceiling and is still a single point of failure, and it can’t isolate an upload spike from the read-heavy watch path. You need many instances and separation of concerns.

2. Rejected. Run everything in one big service for simplicity.

   Coupling uploads/encoding (write) with watch-metadata/search (read) means a surge in one takes down the other. Their traffic shapes are totally different — isolate them.

3. The call. Load balancer + stateless service copies; split read vs write planes.

   Run many stateless instances behind a load balancer with a hot-metadata cache, and separate upload, watch-metadata and search so each scales — and fails — independently, keeping the 99% read path resilient when writes surge.

Owners want view counts and watch time, but a DB write per play (and a counter bump on a viral video) would hammer it. How?

1. The call. Emit lightweight watch events to a stream; aggregate asynchronously.

   Plays emit events into an analytics pipeline; counts aggregate in the background (approximated for hot videos), and recommendations train on the same stream — never on the playback critical path. If analytics lags, playback is unaffected.

2. Rejected. Increment a counter row in the DB on every play.

   A synchronous counter bump per play on a viral video is a write hotspot that can melt the DB and adds latency to playback. Counting must be async and off the hot path.

3. Rejected. Count views in the player and trust the client.

   Client-only counts are unverifiable and easily gamed, and still need to reach the server. Emit events to a pipeline that aggregates and validates server-side.