Designing YouTube: From One Upload to a Video Anyone Can Play
Algomi Research · Created 2026-09-26 · Updated 2026-10-15 · System Design
Harsh's dal-bati video
Harsh is 17 and lives in Kota. He films a 2 GB video, Dal Bati in 10 Minutes, and uploads it to VidKhazana over a connection that drops twice. By evening it has a million views. One of them is his grandmother in their village, on a 2G phone. (Harsh, VidKhazana, Nandini and every number here are made up for teaching.)
Nandini designs VidKhazana's video pipeline. She thinks of it as a school film club. A student hands in a home video shot on a phone. Classrooms have different screens and connections, so a volunteer makes several copies (a big one for the hall projector, a small one for a slow tablet) and puts the popular ones on shelves near each classroom.
A video platform does the same at huge scale: accept an upload, prepare many versions, and keep copies near viewers. This guide designs on-demand video sharing in the style of YouTube. It is an original interview design, not the internal architecture of any named company.
One public fact helps: YouTube's database team built a MySQL scaling layer, Vitess, because a single database could no longer handle its write traffic. Live streaming is a separate problem, covered in our Hotstar guide.
| What happens to the video | Idea it forces |
|---|---|
| "The upload dropped twice at 60%" | Direct-to-storage, resumable uploads |
| "It's uploaded, so why can't anyone watch it yet?" | Processing as an idempotent workflow |
| "Grandma's on 2G and Harsh's friends are on a 4K TV" | A ladder of renditions and adaptive playlists |
| "A million people pressed play" | Access check first, segments from the CDN |
| "The view counter froze the database" | Counting through events, not a hot row |
| "One database can't keep up with the metadata" | Sharding behind a routing layer |
In 30 seconds, as an architect would frame it: "Creators upload in parts, directly to object storage, using a scoped URL. The service verifies the checksum and queues processing durably. Transcoding workers split the video into chunks and encode a ladder of renditions in parallel, with deterministic output keys so retries are harmless, and the video becomes Ready only when every required rendition and playlist exists. Playback checks visibility, returns a master playlist, and the player pulls short segments from CDN edges, adapting quality to the network. Views and likes flow through an event log into aggregated counters. Metadata scales with caches, replicas and eventually sharding behind a router like Vitess."
1. The rules, and what to store
Creators upload large files and may resume after a broken connection. Viewers search, watch, like and comment. Each video is public, unlisted or private. Processing takes time, so a video isn't watchable the instant its upload ends.
| Rule | Why it matters |
|---|---|
| An upload must survive a broken connection | Files are large and networks are unreliable |
| A video is playable only after processing succeeds | Half-processed video must not reach viewers |
| Visibility is checked when a viewer asks | A private video must stay private, including on caches |
| Playback adapts to the viewer's connection | A slow phone and a fast TV both need a smooth stream |
| View counts may lag slightly | Exact instant totals would be very expensive |
| Processing steps may repeat | Workers crash, so every step must be safe to redo |
Recommendations, ads, copyright matching and creator payments are separate systems. This guide covers the path from upload to playback.
| Record | Main fields | Responsibility |
|---|---|---|
| Video | video_id, owner_id, title, visibility, state | Product metadata and lifecycle |
| UploadSession | upload_id, video_id, bytes_received, state | Resumable upload progress |
| Original | video_id, object_key, checksum | The uploaded file in object storage |
| Rendition | video_id, resolution, bitrate, codec, playlist_key | One playable version |
| Segment | rendition, index, object_key | A few seconds of one rendition |
| Comment and reaction | video_id, user_id, text, created_at | Social data, partitioned by video |
| ViewEvent | video_id, viewer, timestamp | A raw event, counted later |
Product metadata (who owns it, who may watch) answers "may this person see the video?" Storage keys answer "where are its bytes?" Keeping them separate lets you move bytes without touching permissions.
2. "The upload dropped twice": upload straight to storage
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
See plans