A video platform lets creators upload videos and lets viewers watch them on anything from a phone on a train to a living-room TV. The upload side is a batch pipeline that turns one large source file into dozens of smaller ones. The watch side is almost entirely a content delivery problem: moving a very large number of bytes to viewers cheaply, without stalls.
\nInterviewers like this question because the interesting parts aren't in the web tier. They're in how you get multi-gigabyte files in reliably, how you split transcoding into parallel work, how adaptive bitrate streaming actually works, and why bandwidth cost shapes the architecture. It builds on the primer's CDN and asynchronism chapters.
","headings":[]},{"id":"requirements-and-estimates","title":"Requirements and estimates","html":"Scope:
\nThe numbers below are assumptions for a mid-to-large platform, chosen to keep the arithmetic readable.
\nThe headline is the ratio. Egress (about 40 PB a day) is over a hundred times ingress (300 TB a day). Read bandwidth is the dominant cost, so the design should spend money on the write side, like extra encoding work, if it saves bytes on the read side. Estimation covers this kind of reasoning.
","headings":[{"id":"requirements-and-estimates","title":"Requirements and estimates","depth":3},{"id":"watching","title":"Watching","depth":4},{"id":"uploading","title":"Uploading","depth":4}]},{"id":"api-and-data-model","title":"API and data model","html":"Uploads use a short REST handshake; the bytes themselves bypass your servers:
\nPOST /videos -> {video_id, upload_id, part_urls[]}\nPOST /videos/{id}/upload:complete {upload_id, parts: [{n, etag}]}\nGET /videos/{id} -> metadata, status, thumbnails\nGET /videos/{id}/play -> {manifest_url, license_url?}\nPOST /videos/{id}/views {session_id, position}GET /play returns the URL of a manifest on the CDN, not the video. The player fetches everything else from the CDN.
The main records:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Record | Store | Notes |
|---|---|---|
videos | Sharded relational DB | id, owner, title, duration, status (uploading, processing, ready, blocked), visibility |
renditions | Same DB | video_id, codec, resolution, bitrate, manifest path |
jobs / tasks | Workflow store | DAG state per video, retries, timings |
view_counts | Counter store | Aggregated, updated in batches |
| Source and segments | Object storage | Immutable files addressed by path |
Metadata is small, relational and read-heavy, so a sharded SQL database with a cache in front works well. YouTube built Vitess to scale its MySQL databases this way. The video files go in object storage, never in the database, the same split the primer's Pastebin design makes for paste contents.
","headings":[{"id":"api-and-data-model","title":"API and data model","depth":3}]},{"id":"high-level-design","title":"High-level design","html":"Pushing 600 MB through your API servers wastes their bandwidth and ties up connections for minutes. Instead:
\nPOST /videos. The API creates a videos row with status uploading, starts a multipart upload in object storage, and returns pre-signed URLs, one per part. A pre-signed URL is a link signed with the service's credentials that allows exactly one kind of operation (here, a PUT to one part of one object) until it expires. It isn't single-use: anyone holding it can repeat that operation until then.complete with the list of parts. Object storage stitches them into one object and emits an event, which starts processing.Part sizes depend on the store. Amazon S3, for example, requires parts of at least 5 MiB except the last, and allows up to 10,000 parts per upload. Choose part sizes so a large file stays well under the part limit and a failed part is cheap to retry. If you'd rather not depend on one vendor's multipart API, the open tus protocol defines resumable uploads over plain HTTP.
\nThe trade-off is that the API no longer sees the bytes, so validation happens afterward in the pipeline. Treat every upload as untrusted until it has been probed.
","headings":[{"id":"high-level-design","title":"High-level design","depth":3},{"id":"uploads-with-pre-signed-urls","title":"Uploads with pre-signed URLs","depth":4}]},{"id":"the-transcoding-pipeline","title":"The transcoding pipeline","html":"A source file arrives in whatever format the creator's camera or editor produced. The pipeline turns it into a set of renditions every player can handle, plus thumbnails and captions. It's naturally a directed acyclic graph of tasks:
\nready and make the manifest URL live.How to run it:
\nA viewer's bandwidth changes from second to second. Adaptive bitrate (ABR) streaming handles this by encoding the video at several quality levels, cutting each into short segments, and letting the player choose a level for each segment.
\nAn example ladder (assumed values; real ladders vary by content):
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Rendition | Resolution | Video bitrate |
|---|---|---|
| 240p | 426×240 | 0.4 Mbps |
| 360p | 640×360 | 0.8 Mbps |
| 480p | 854×480 | 1.4 Mbps |
| 720p | 1280×720 | 2.8 Mbps |
| 1080p | 1920×1080 | 5.0 Mbps |
That ladder adds up to 10.4 Mbps, which is where the \"about 10 Mbps of output\" in the estimate came from.
\nThe two main formats are HLS (HTTP Live Streaming, from Apple, published as RFC 8216) and MPEG-DASH (an ISO standard). Both work the same way:
\nA trimmed HLS master playlist:
\n#EXTM3U\n#EXT-X-STREAM-INF:BANDWIDTH=900000,RESOLUTION=640x360\n360p/index.m3u8\n#EXT-X-STREAM-INF:BANDWIDTH=3100000,RESOLUTION=1280x720\n720p/index.m3u8\n#EXT-X-STREAM-INF:BANDWIDTH=5500000,RESOLUTION=1920x1080\n1080p/index.m3u8BANDWIDTH is the peak bitrate in bits per second, including audio and container overhead, which is why it's a little above the video bitrate in the table.
The player downloads the master playlist, picks a starting rendition, and then fetches segments over ordinary HTTP. Before each segment, it looks at its recent download throughput and how many seconds of video are buffered, and moves up or down the ladder. Because everything is plain HTTP GETs of immutable files, every segment is cacheable by any CDN, which is the main reason HTTP-based streaming displaced older stateful protocols such as RTMP for delivery.
\nPractical notes:
\nAt around 9 Tbps peak, nearly all playback traffic must come from CDN caches, and egress is the largest bill. To make the cost concrete, suppose a blended delivery price of $0.005 per GB. That number is made up for the arithmetic; real contracts vary widely with volume. Then 40 PB a day is 40 × 10⁶ GB × $0.005 = $200,000 a day. Every percent of bitrate you save is worth $2,000 a day.
\nPopularity is heavily skewed: a small share of videos gets most of the views, and a long tail is rarely watched. That changes how you treat each:
\nMention both and keep moving unless the interviewer digs in:
\nGET /play returns a license URL.The file was being sent as many independent parts to pre-signed URLs, so the parts that completed are already stored. When the app reconnects, it asks the API which parts have arrived, requests fresh pre-signed URLs if the old ones expired, and uploads only the missing parts. Then it calls complete. Nothing is re-sent from the beginning, and the API servers never carried the bytes.
The player switches renditions at segment boundaries, and each segment must start with a keyframe so it can be decoded without earlier data. If the 480p and 720p segments started at different times, switching would leave a gap or overlap and a visible glitch. Aligned keyframes, set during encoding, make segment N of every rendition cover the same time span.
\nNot everything. The encoding cost is paid once per video, while the bandwidth savings are paid back on every view, so it pays off only for videos that get enough views, and only for viewers whose devices can decode AV1. A common policy is to encode a widely supported codec for everything and add the more efficient one once a video crosses a popularity threshold. Use the estimate to find roughly where the break-even point is.
\nThe task was never marked complete, so after its visibility timeout or lease expires, the queue hands it to another worker. Because the task writes to a deterministic path (for example video/720p/chunk-37), the retry overwrites any partial output instead of creating a second copy. The packaging task only starts when the scheduler sees all chunks complete, so it never reads a half-written chunk.
Store them more cheaply: move older, rarely watched sources and renditions to a cheaper storage class or erasure-coded storage. And don't produce what nobody watches: skip high rungs or extra codecs for new videos until they get views, and transcode on demand if someone does ask. Both trade a little latency for a rare viewer against a lot of storage and compute.
\nBANDWIDTH means.