Design a Video Streaming Platform (YouTube)

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: What Is a Video Platform?

A TV Station Where Anyone Can Broadcast

Imagine a TV station with one unusual rule: anyone can walk in with a tape and put it on the air. The station doesn't broadcast on one channel at one quality. Every viewer tunes in whenever they like, on a phone in a train tunnel, a laptop on office Wi-Fi or a 4K TV, and each one gets a picture that fits their screen and their connection.

That is a video platform. People upload a video once, and many people watch it, on many devices, over fast and slow networks. YouTube, Vimeo and every company's internal video portal work this way.

A few words we'll use all page:

What Makes It Hard

• Raw video is enormous. A 10-minute phone video is hundreds of megabytes; a camera file can be tens of gigabytes. Moving it through our servers is the first mistake.
• One upload becomes many files. Every video is converted into several sizes and formats, and each conversion is real compute. Transcoding is the platform's biggest compute bill.
• Delivery is the biggest bill of all. Every view sends tens of megabytes. Multiply by billions of views a day and the bandwidth bill dwarfs everything else. That fact drives every decision in Rounds 2 and 3.
• Viewers are impatient. People leave if playback takes more than a couple of seconds to start or stalls in the middle.

The Question the Whole Loop Answers

How do we turn any upload into smooth playback on any device and network, at a cost we can afford?

The answer grows every round:

• Round 1: upload straight to storage, transcode into a small ladder with a managed service, cut it into segments with a manifest, and serve it through a CDN with signed cookies.
• Round 2: transcode in parallel chunks on a Spot GPU fleet, shield the origin from viral bursts, count views without a hot row, tier the petabytes, and add DRM. Delivery turns out to be nearly 90% of the bill.
• Round 3: add live streaming, spread delivery across several CDNs, catch copyrighted and harmful uploads, enforce country rules, and cut the cost of every view-hour by 30%.

---

Round 1 · Mid-level · "Training Videos for One Company"

~35 min · SDE II (L5) · 1 region + CloudFront · 500 uploads/day · 100K views/day · playback starts < 2 s · watchable within an hour · 99.9%

R1.1 Establish Design Scope

The interviewer says: "Our company wants an internal video site. Teams record trainings and all-hands talks, upload them, and employees watch them. Design it." Before drawing anything, we ask.

Out of scope for this round: resumable uploads over flaky mobile networks, view counts, DRM, and anything public.

R1.2 Functional Requirements, Derived Step by Step

Not yet: resumable uploads for huge files over bad networks, adaptive bitrate at global scale, view counts.

R1.3 Non-Functional Requirements: the Questions

We name each quality first; the numbers come in R1.7.

• Playback start time. How long from pressing play to the first frame? Viewers notice anything over about 2 seconds.
• Smoothness. Playback must not stall on a hotel Wi-Fi or a phone on 4G. That needs more than one quality level.
• Durability. A recorded all-hands can't be recorded again. The original upload must not be lost.
• Cost. Compute for transcoding, storage that grows every day, and delivery bytes. We'll find out which one dominates.

R1.4 The API

Create a video and get upload URLs

httpCopy
POST /v1/videos HTTP/1.1
Host: video.corp.example
Authorization: Bearer <SSO access token>
Content-Type: application/json

{ "title": "Q3 all-hands", "channel_id": "ch_eng", "file_name": "allhands.mp4", "size_bytes": 4500000000 }

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{
  "video_id": "v_8f3k2m",
  "upload": {
    "type": "multipart",
    "upload_id": "mpu_2b91",
    "part_size_bytes": 67108864,
    "parts": [
      { "part_number": 1, "url": "https://corp-video-raw.s3.us-east-1.amazonaws.com/raw/v_8f3k2m/source?partNumber=1&uploadId=mpu_2b91&X-Amz-Signature=..." },
      { "part_number": 2, "url": "https://corp-video-raw.s3.us-east-1.amazonaws.com/raw/v_8f3k2m/source?partNumber=2&uploadId=mpu_2b91&X-Amz-Signature=..." }
    ],
    "urls_expire_at": "2026-10-05T15:00:00Z"
  }
}

• Files up to 100 MB get one pre-signed PUT URL. Bigger files get a multipart upload: the file is sent in parts (here 64 MiB each), each part retried on its own. A 4.5 GB file is ⌈4,500,000,000 ÷ 67,108,864⌉ = 68 parts.
• A pre-signed URL is a normal S3 URL with a signature in the query string. It lets the browser upload one object (or one part) directly to S3 for a limited time, without AWS credentials.

Finish the upload

httpCopy
POST /v1/videos/v_8f3k2m/complete HTTP/1.1
Authorization: Bearer <SSO access token>
Content-Type: application/json

{ "upload_id": "mpu_2b91", "parts": [ { "part_number": 1, "etag": "\"a54f...\"" }, { "part_number": 2, "etag": "\"77c1...\"" } ] }

httpCopy
HTTP/1.1 202 Accepted
Content-Type: application/json

{ "video_id": "v_8f3k2m", "status": "PROCESSING", "status_url": "/v1/videos/v_8f3k2m" }

Check status and metadata

httpCopy
GET /v1/videos/v_8f3k2m HTTP/1.1
Authorization: Bearer <SSO access token>

jsonCopy
{ "video_id": "v_8f3k2m", "title": "Q3 all-hands", "status": "READY", "duration_s": 3540,
  "renditions": ["1080p", "720p", "480p", "360p"], "created_at": "2026-10-05T14:02:11Z" }

Start playback

httpCopy
GET /v1/videos/v_8f3k2m/playback HTTP/1.1
Authorization: Bearer <SSO access token>

httpCopy
HTTP/1.1 200 OK
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQi...; Domain=media.corp.example; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=Qm9i...; Domain=media.corp.example; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=media.corp.example; Path=/; Secure; HttpOnly
Content-Type: application/json

{ "manifest_url": "https://media.corp.example/v/v_8f3k2m/master.m3u8", "cookies_expire_at": "2026-10-05T15:10:00Z" }

Status codes

Recap

• Uploads go straight to S3 with pre-signed URLs; big files in parts.
• Playback returns a manifest URL plus cookies that unlock the video's segments.
• Four statuses; a video is only playable when READY.

R1.5 Design Evolution: From One File to a Streamed Ladder

Each step is a problem, your turn to think, the answer, and what it costs us.

Step 1.0: The Baseline

A web app on two EC2 instances. The browser uploads the file to the app, which writes it to S3. To play, the browser gets an <video src="..."> pointing at the app, which streams the original file back from S3.

Synthesizing vector architecture diagram...

Every byte, in and out, passes through our app servers, and every viewer gets the same file the camera produced.

It works for a demo. Two problems show up in the first week.

Step 1.1: Uploads Saturate Our Servers

Step 1.2: A 4 GB Camera File Won't Play on Phones

Step 1.3: Playback Stutters on Slow Networks

Step 1.4: Viewers Far From Our Region Buffer

Primitive: Distributed Cache Patterns and Eviction

Step 1.5: "Is My Video Ready Yet?"

Step 1.6: Anyone With the Link Can Watch

Round 1 Step Summary

R1.6 Architecture v1

Synthesizing vector architecture diagram...

Bytes never touch our code: uploads go to the raw bucket and viewers read through CloudFront. Our code only moves the status along and hands out permissions.

S3 layout

The Videos table

Title search uses a small OpenSearch domain fed from the table's DynamoDB stream (the table's own change log) by a Lambda function. We never write to both from the API: a crash between the two writes would leave them different forever, while the stream carries every committed change.

Tracing an upload: the all-hands, 1 hour, 4.5 GB

Synthesizing vector architecture diagram...

At 20 Mbps of office upload bandwidth, 4.5 GB takes 4.5 × 8,000 ÷ 20 = 1,800 s = 30 minutes; the transcode then takes minutes to tens of minutes (MediaConvert gives no fixed time, so we measure it). Both fit "watchable within an hour" only if the upload link is that fast, which is why the 1-hour target is measured from upload complete.

Tracing playback start

Synthesizing vector architecture diagram...

The first segment at 480p is 4 s × (1.2 + 0.128) Mbps = 5.31 Mb ≈ 664 KB. R1.7 adds up the whole path.

R1.7 Numbers

Targets

Traffic and bytes

Notice the ratio: we store about 11 TB of renditions a month but send about 342 TB. Every view re-sends the bytes.

Playback start budget, P95, cache miss, a remote office on a 10 Mbps link (every step waits for the one before, so they add):

On a cache hit the three misses shrink to about 30 ms each and the total is about 1.0 s.

Monthly cost (us-east-1 list prices; CloudFront per-area tiered prices; 30.4-day month)

In month 1, storage is only about 22.6 TB × $0.023 ≈ $520, so the total is about $26,735. Either way delivery is about 70% of the bill, even for an internal site. MediaConvert, the thing people worry about, is 17%.

R1.8 Trade-Offs

Managed transcoding vs our own fleet

At 500 videos a day, the difference is one engineer's time for a month a year. That's COST 11 (the cost of effort): the managed service wins. Round 2 runs the same comparison at 4.32M videos a day and gets the opposite answer.

HLS vs DASH

With CMAF (the common fMP4 segment format both use), the same segment files can serve both: only the manifests differ. We start with HLS alone and can add a DASH manifest later over the same segments.

How many renditions?

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Sends uploads straight to S3 with pre-signed multipart URLs and explains why proxying is wrong.
• Explains codec vs container and why we transcode into a ladder.
• Explains ABR: aligned keyframes, segments, master and media playlists, and why the player chooses.
• Puts a CDN in front with a private origin and different cache rules for segments and manifests.
• Tracks status with conditional writes and makes retries and notifications idempotent.
• Protects private video with signed cookies, and says why not signed URLs.
• Finds that delivery, not transcoding, dominates the bill.

Follow-up questions

1. "Why not have the browser play the MP4 file directly with a <video> tag?" Answer: one file means one bitrate for every network and device. It can't adapt mid-video, and a 1080p file stalls on a weak connection. Segments plus manifests let the player switch every 4 seconds.

2. "Why not trigger transcoding from the complete API call instead of the S3 event?" Answer: the API call and the object's existence can disagree: a client could call complete twice, or crash before calling it after S3 assembled the object. The S3 event fires exactly when the object exists; the conditional status write makes duplicates harmless.

3. "An employee leaves the company. Can they still watch?" Answer: for at most an hour, until their cookies expire; the API refuses to renew them because SSO does. If that hour matters, shorten the cookie lifetime; the player renews in the background.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "Millions of Uploads, Billions of Views"

~40 min · Senior SDE (L6) · 1 processing region, CloudFront worldwide · 4.32M uploads/day · 5B views/day · time to first frame P95 < 800 ms · rebuffering < 0.5% of sessions · 720p ready within 0.5× the video's length · 99.99% playback

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "We built an internal video site: 500 uploads and 100,000 views a day. Browsers upload straight to S3 with pre-signed multipart URLs, so no bytes pass through our servers. An S3 event starts a MediaConvert job that transcodes each upload into four H.264 renditions, 360p to 1080p, cut into 4-second segments with aligned keyframes, with HLS master and media playlists. Players use adaptive bitrate: they start at 480p and switch rendition every segment as bandwidth changes. CloudFront serves everything from a private bucket; segments are cached for a year because they never change, manifests for 5 minutes. A DynamoDB state machine with conditional writes tracks each video from UPLOADING to READY, and signed cookies with a 1-hour expiry keep the videos private. About $30K a month, and 70% of it is delivery, not transcoding. Open costs: one managed transcoder billed per minute, no resumable uploads for bad networks, no view counts, no DRM, and nothing public."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: bytes go around our code, not through it.

Round 1 step summary

Open costs: a per-minute transcoder, fragile uploads on mobile, no counts, no DRM, one audience.

R2.1 The Scope Raise

Interviewer: "Now it's public, like YouTube. People upload from phones everywhere. Some videos go viral and get millions of viewers in an hour. We need view counts, and some partner content must be protected by DRM."

Scope change

The "Not yet" list from R1.2 comes back: resumable uploads, ABR at global scale and view counts are all in scope now.

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

Resumable upload sessions

httpCopy
POST /v1/uploads HTTP/1.1
Authorization: Bearer <access token>
Content-Type: application/json

{ "file_name": "trip.mov", "size_bytes": 1500000000, "content_type": "video/quicktime", "title": "Iceland in 10 minutes" }

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{ "upload_id": "up_71c9", "video_id": "v_Q2x9", "part_size_bytes": 16777216, "part_count": 90,
  "checksum_algorithm": "CRC32C", "session_expires_at": "2026-10-12T14:00:00Z" }

• Part size adapts to the file. S3 allows at most 10,000 parts, each 5 MiB to 5 GiB. We use 16 MiB, or more when the file needs it: ⌈size ÷ 10,000⌉ rounded up to a whole MiB. 1.5 GB ÷ 16 MiB = 89.4, so 90 parts. A 256 GB file needs 25.6 MB per part, so 25 MiB (26,214,400 bytes): 9,766 parts.
• URLs in batches. GET /v1/uploads/up_71c9/part-urls?from=1&count=20 returns 20 pre-signed part URLs valid for 1 hour. The phone asks for more as it goes, so a URL is never older than an hour. (A pre-signed URL signed with temporary credentials also stops working when those credentials expire, another reason to hand them out in small batches.)
• Per-part checksums. Each part is sent with a CRC32C checksum that S3 verifies on arrival; a part damaged in transit is rejected and re-sent.
• Resume. GET /v1/uploads/up_71c9 asks S3 which parts it has (ListParts) and returns { "parts_received": [1, 2, …, 57] }. The phone sends only the rest.
• Complete. POST /v1/uploads/up_71c9/complete assembles the object. The session expires after 7 days; the API checks session_expires_at itself, and an S3 lifecycle rule cleans up the parts.

View events

httpCopy
POST /v1/views/events HTTP/1.1
Content-Type: application/json

{ "events": [ { "view_id": "vw_5e1b0c7a", "video_id": "v_Q2x9", "type": "qualified", "position_s": 31.2, "watch_s": 30.0, "client_ts": "2026-10-05T14:03:02Z" } ] }

httpCopy
HTTP/1.1 202 Accepted

• The player creates one random view_id when playback starts. It sends start, qualified (once the viewer has watched long enough to count as a view, a threshold we choose) and end: three small requests per view.
• 202 means "queued", not "counted".

Playback by device capability

httpCopy
POST /v1/videos/v_Q2x9/playback HTTP/1.1
Content-Type: application/json

{ "codecs": ["avc1", "hvc1"], "drm": ["fairplay"], "screen_height": 1170 }

jsonCopy
{ "manifest_url": "https://media.example.com/v/3f/v_Q2x9/r1/h264/master.m3u8",
  "license_url": null, "cookies_expire_at": "2026-10-05T14:33:00Z" }

The API picks the manifest for the codecs the device can decode (H.264 everywhere; HEVC for the 4K rung on devices that have it; AV1 comes in Round 3) and, for protected titles, the DRM system the device supports.

DRM licenses (described). For protected titles, the player's DRM module sends a license request to our license service with its playback token. The service checks the viewer's rights and returns the content key, encrypted so only that device's DRM module can use it (step 2.7).

R2.4 Design Evolution: From One Job to a Parallel Pipeline

Step 2.1: Transcoding a 1-Hour Video Takes Hours

Primitive: Message Queues vs Event Streams

Step 2.2: The GPU Fleet Costs a Fortune

Primitives: Circuit Breaker, Bulkhead and Fault Tolerance Patterns (the fast and full lanes are bulkheads: a 4K backlog can never delay 720p) · Drill: Message Queue for an Order Pipeline. A worker that crashes halfway through a task never deletes the message, so it reappears after the visibility timeout and another worker redoes the whole task (outputs are idempotent); a task that fails 5 times goes to a dead-letter queue and marks the video FAILED. We use a queue rather than calling workers directly because workers come and go with Spot, uploads arrive in bursts of 3×, and the two lanes need different priorities: the queue absorbs all three.

Step 2.3: A Viral Video's First Minute Floods the Origin

Drill: CDN Edge Image Delivery (the same two questions, for images)

Step 2.4: Egress Is Most of the Bill

Step 2.5: A Counter Row per Video Melts on Viral Videos

Primitive: Database Sharding and Partition Keys

Step 2.6: Storage Grows by Petabytes a Day

Step 2.7: Partner Content Must Be Protected

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Four independent paths: uploads land in S3, processing is a queue-driven fleet, delivery never touches our servers except for playback authorization, and views flow through a stream into conditional writes.

Data layout

Search is fed the same way as Round 1, from the Videos table's DynamoDB stream, now into a larger OpenSearch cluster.

Trace: upload to 720p ready, a 10-minute 1.5 GB phone video

Synthesizing vector architecture diagram...

The upload itself took about 10 minutes at 20 Mbps (1.5 GB × 8 ÷ 20 Mbps = 600 s); processing starts only when it's complete. Full-lane tasks (≈ 32 s each) run in parallel, so under normal load READY follows a couple of minutes after PLAYABLE.

Trace: a DRM playback

Synthesizing vector architecture diagram...

The license call happens in parallel with fetching the first segment, so it adds about one round trip to the start, not a full sequence.

R2.6 Numbers and Cost

Traffic

Storage

Bandwidth

Memory

Time to first frame, P95 < 800 ms. The playback call and the TLS connection to CloudFront happen while the watch page loads, so they're off the critical path. After "play" (dependent steps add; parallel fetches count once):

That only holds on a cache hit, which is why prefetching (step 2.3) and the hit ratio matter: a miss adds 100–200 ms, and the long tail of rarely watched videos lives in the slowest 5%.

Quotas to raise before launch (current defaults). CloudFront: 150 Gbps and 250,000 requests a second per distribution; we need 43.4 Tbps and about 9 million requests a second on average (775 billion a day ÷ 86,400), so this is a conversation with AWS, not a form. EC2: GPU-family vCPU quotas. Step Functions: we fit the default 5,000 state transitions a second. SQS: 120,000 in flight per standard queue.

Monthly cost (us-east-1 list prices; CloudFront per area and tiered; end of year one for storage)

We assume where viewers are: 30% US/Mexico/Canada, 25% Europe, 15% India, 15% the Hong Kong/Singapore/Southeast Asia group, 10% South America and 5% Japan. Each area's volume is priced on its own tiers (an assumption about how the tiers aggregate), and at petabyte volumes nearly all of it sits in the "over 5 PB" tier.

Delivery (data out plus requests) is $568M, 93% of the bill. The GPU fleet everyone worries about is 1.9%. Per view-hour: $611.9M ÷ 12.67 billion ≈ $0.048.

Three things the table teaches:

• Segment count is money. Requests alone are $29M a month, driven by 4-second segments with separate audio. Round 3 revisits segment length.
• Where the bytes don't go. GPU workers read the raw file from S3 through a VPC gateway endpoint (free). Through a NAT gateway, 6.48 PB a day at $0.045/GB would add about $292K a day. And nothing on the hot path crosses AZs between our own instances: S3 is regional, so reading it from any AZ costs nothing extra, while instance-to-instance traffic across AZs is billed $0.01/GB in each direction.
• Upload acceleration isn't free. Transfer Acceleration costs $0.04/GB on top of free S3 ingress; that's $2M a month even at 25% use. Round 3 moves uploads to regional buckets instead.

R2.7 Trade-Offs

MediaConvert vs our own fleet at this scale

We keep MediaConvert for unusual inputs our fleet rejects (exotic professional codecs), so the fleet stays simple.

Chunk size

Segment length (what players fetch; separate from chunks)

Apple's HLS authoring guidance recommends 6-second segments. We chose 4 s for faster adaptation on mobile networks; Round 3 moves VOD to 6 s once request costs matter more.

Codec ladder

Every video gets H.264; HEVC only for the 4K rung; AV1 only for popular videos (Round 3).

Exact vs approximate counts

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a strong senior (L6) answer shows

• Splits transcoding in time at keyframes, explains closed GOPs, frame-count boundaries and whole-file audio, and chooses a chunk size with reasons.
• Sizes the GPU fleet from rendition-hours, labels the throughput assumption, and uses Spot with leases that don't depend on a database clock.
• Makes retries safe everywhere: idempotent outputs, conditional completion, and callbacks re-sent when a retry finds the work already recorded.
• Explains how misses multiply through a CDN and what Origin Shield actually collapses.
• Does the egress math and concludes that delivery, not compute, is the bill.
• Counts views without a hot row and without double-counting replays.
• Tiers storage by access pattern and notices the per-object costs.
• Separates access control (signed cookies) from copy protection (DRM).

Follow-up questions

1. "Why not transcode on the phone before uploading?" Answer: phones could shrink the upload, but we'd lose the original quality forever, battery and heat would suffer, and results would vary by device. Some apps do a light re-encode of very large files; the ladder is still made on our side from the best source we have.

2. "A popular creator uploads at the daily peak. Is their 720p still fast?" Answer: yes. The fast lane is about 7% of the GPU work and is always polled first, with an on-demand floor, so it keeps up even at 3× the average upload rate. The 1080p and 4K rungs may lag by hours at the peak; the master playlist gains them when they're ready.

3. "Why doesn't the count use exactly-once transactions?" Answer: it doesn't need them. Flink's checkpointed state makes the dedupe exact within its 24 hours, and the conditional last_window makes the write idempotent per window. Anything left over (late events, fraud) is fixed by recomputing from the stored events.

Interview gotchas from this round's wrong answers

---

Round 3 · Architect · "Live, Global, and Paying for Every Byte"

~45 min · Principal (L7) · 3 processing regions, 3 CDNs plus ISP caches · VOD as in Round 2, plus a live final with 10M viewers at once · live latency about 4 s (low-latency mode) or 10 s (standard) · cost per view-hour down 30%

R3.0 Where We Left Off

Round 2 in 60 seconds. "We run a public platform from one processing region: 500 hours uploaded a minute, 4.32M uploads and 5 billion views a day. Phones upload through resumable sessions with adaptive part sizes. Each upload is probed and planned as 40-second chunks on keyframe boundaries; a fast lane makes 720p and below within about 39 s for a 10-minute video, and a full lane adds 1080p and 4K. About 22,500 GPUs on average, 80% Spot, with SQS visibility timeouts as leases, idempotent outputs and callbacks re-sent on retry. Renditions are single CMAF files with byte-range playlists in S3 Intelligent-Tiering; raw files go from Standard to Glacier Instant Retrieval to Deep Archive. CloudFront with Origin Shield serves 43.4 Tbps on average at a 98.5% hit ratio; players start low and climb, capped by screen size. Views flow through Kinesis and Flink into one conditional write per video per minute. DRM protects partner titles. About $612M a month at list prices, $0.048 per view-hour, and 93% of it is delivery. Open costs: no live, one CDN, one processing region, nothing catches copyrighted or harmful uploads, no country rules, and the bill."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: a queue-driven transcoding fleet, one CDN with a shield, a stream for counts.

Round 2 step summary

Open costs: VOD only, one CDN, one region, no rights or moderation, no country rules, $0.048 per view-hour.

R3.1 The Scope Raise

Interviewer: "We're adding live: creators stream every day, and next summer we have the rights to a football final. Rights holders want their content caught when people re-upload it. Harmful content must come down fast, and some countries require specific videos to be blocked there. And the CFO wants the cost per view-hour down 30%."

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

Create a live stream

httpCopy
POST /v1/live/streams HTTP/1.1
Authorization: Bearer <access token>
Content-Type: application/json

{ "title": "Cup final", "latency_mode": "low", "redundant_ingest": true }

jsonCopy
{ "stream_id": "ls_77ab",
  "ingest": [
    { "protocol": "srt", "url": "srt://ingest-a.live.example.com:9000", "passphrase_ref": "sec_91" },
    { "protocol": "srt", "url": "srt://ingest-b.live.example.com:9000", "passphrase_ref": "sec_92" }
  ],
  "playback_url": "https://live.example.com/l/ls_77ab/master.m3u8" }

• RTMP (Real-Time Messaging Protocol, over TCP; RTMPS with TLS) is what most streaming software sends. SRT (Secure Reliable Transport, over UDP) resends lost packets within a latency window we choose and encrypts the stream; it holds up better over long, lossy links. We accept both; the final uses SRT to two independent ingest points.
• latency_mode is low (about 4 s) or standard (about 10 s). R3.6 shows why not everyone gets low.

Rights-holder references

httpCopy
POST /v1/rights/references HTTP/1.1
Authorization: Bearer <partner token>
Content-Type: application/json

{ "asset_id": "ref_ucl_final_feed", "upload_id": "up_9f2", "match": ["audio", "video"],
  "policy": [ { "territories": ["DE", "AT"], "action": "block" }, { "territories": ["*"], "action": "monetize" } ] }

Moderation and legal decisions

httpCopy
POST /v1/decisions HTTP/1.1
Authorization: Bearer <reviewer token>
Content-Type: application/json

{ "video_id": "v_Q2x9", "action": "block", "scope": { "countries": ["TR"] },
  "source": "legal", "reason_code": "court_order", "reference": "case 2026/1142" }

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{ "decision_id": "dec_01J9ZK4T7M", "video_id": "v_Q2x9", "effective": "immediately" }

A decision is never edited. Lifting it is a new decision that names it: { "action": "lift", "lifts": "dec_01J9ZK4T7M" }.

Availability

GET /v1/videos/v_Q2x9/availability?country=TR returns { "available": false, "reason": "legal" }, and playback there returns 451 Unavailable For Legal Reasons.

R3.4 Design Evolution: Live, Rules and Money

Step 3.1: Live Streams

Step 3.2: 10M Viewers for a Final

Step 3.3: Catch Copyrighted Uploads

Step 3.4: Harmful Content Must Come Down Fast

Step 3.5: Available in Some Countries, Not Others

Step 3.6: Cut Cost per View-Hour by 30%

Round 3 Step Summary

R3.5 Global Architecture

VOD across three Regions

Synthesizing vector architecture diagram...

Each upload is processed in the Region nearest the uploader, its home. Popular videos are copied to a partner Region; restrictions and metadata are global tables.

• Home Region per video. The upload API sends each upload to the nearest healthy Region; that Region processes and stores it. Its paths start with the Region (/use1/3f/v_Q2x9/...), and the CDN's cache behavior for each prefix points at that Region's bucket, with Origin Shield in the same Region.
• Writes have one home. A video's metadata is written only in its home Region, so the global table's last-writer-wins rule decides nothing in normal operation. Restrictions are append-only. View counts are per Region: each Region's Flink writes its own counter item (VIEWS#use1, VIEWS#euw1, …) with its own last_window, and a video's total is the sum of its items, so Regions never write the same item.
• Popular videos get a second copy. When a video passes 1,000 views a day (about the top 5% of uploads), a job copies its renditions to a partner Region. The CDN's origin group for that prefix lists both, and fails over per request on errors or timeouts from the home bucket: no central automation.

Live

The diagram in step 3.1: two ingest points, two transcoding pipelines in two AZs, one packager origin with Origin Shield, three CDNs, and an archive into the VOD pipeline.

Delivery and policy

Synthesizing vector architecture diagram...

The playback API decides who may watch and where from; the CDNs enforce the same token, country check and blocklist; player measurements steer the next sessions.

Trace: the final starts

Synthesizing vector architecture diagram...

10M joins spread over 15 minutes is 10,000,000 ÷ 900 s ≈ 11,100 playback requests a second, on top of normal VOD traffic. The edges, not our APIs, carry the heavy load.

Trace: a copyrighted upload

Synthesizing vector architecture diagram...

Matching finishes alongside the fast lane, so the restriction exists before the video is public.

Trace: an urgent takedown

Synthesizing vector architecture diagram...

New sessions stop in seconds. Open sessions of a globally blocked video stop when the invalidation completes (usually seconds), because the origin no longer has the files; for any block, they stop within 10 minutes, when their cookies can't be renewed.

R3.6 Numbers and Cost

Live: the final

Per viewer-hour, our CDN delivery at 4 Mbps is 1.8 GB × $0.020 = $0.036, against IVS's $0.096 to $0.144: about 2.7 to 4 times more. That's why creator live is built, not bought.

Live: creators

Fingerprinting and moderation: ≈ $97K and ≈ $9K a month (steps 3.3 and 3.4).

Storage per tier (end of year one, as in Round 2)

(0.595 is the 4K rung's share of the ladder's bytes: 15 ÷ 25.2 Mbps. 0.74 is its share of the GPU work, by pixels.)

VOD cost, before and after (monthly, list prices)

Live is on top: about $0.73M a month for creator transcoding, plus about $1.3M of delivery and requests per final.

R3.7 Trade-Offs

Live latency vs stability

Multi-CDN vs single

Fingerprint sensitivity

Rights holders can ask for shorter thresholds on specific references, after review.

Build vs buy is the table in step 3.6.

What changed from Round 1. Round 1 answered "how do we get a video from a camera to a screen?" with one managed job and one CDN. Round 3 answers "how do we do that for the world, live, under law and on budget?" with three Regions, three CDNs, a live path, and rules that sit beside the catalog. The core never changed: bytes go around our code, not through it; every file is cut into segments any cache can serve; and the player, not the server, adapts to the network.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Golden signals OPS 8 · REL 6

CDN failover procedure REL 5

1. Confirm it's the CDN: errors on one CDN only, across many videos, while the others are healthy.
2. Players are already switching. Check that the other CDNs' error rates stay flat as they absorb traffic.
3. Set the failing CDN's weight to 0 in the steering document and deploy it. Sessions starting from now avoid it.
4. If the others are above 80% of their reserved capacity, set the bitrate caps (720p for live, above-720p VOD capped). Remove the caps when load falls below 60%.
5. Restore the CDN's weight in steps of 10% an hour once its own status and our canaries are clean.

Stuck transcode queue procedure REL 7

1. Is it the fast lane? That's P1: videos aren't becoming watchable.
2. Is the fleet running? Compare instances in service with desired capacity. If Spot capacity is short, raise the on-demand share of the fast-lane group.
3. Are tasks failing? Check the dead-letter queue: one bad input can't block others, but a bad encoder release can fail everything. Roll back the release, then move the dead-letter messages back.
4. Are workflows waiting on callbacks that never came? List running executions older than an hour; for each, read the job item. If all chunks are recorded, re-send the callback (the same rule as step 2.2).

Go deeper: CLI playbook

Plain commands an on-call engineer runs one at a time. Replace names, IDs and ARNs with real ones.

textCopy
# 1. Oldest message in the fast lane (a CloudWatch metric, not a queue attribute)
aws cloudwatch get-metric-statistics --region us-east-1 --namespace AWS/SQS --metric-name ApproximateAgeOfOldestMessage --dimensions Name=QueueName,Value=transcode-fast --start-time 2026-10-05T09:00:00Z --end-time 2026-10-05T09:30:00Z --period 60 --statistics Maximum

# 2. Messages waiting and in flight
aws sqs get-queue-attributes --region us-east-1 --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/transcode-fast --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

# 3. Fast-lane fleet and an emergency scale-up
aws autoscaling describe-auto-scaling-groups --region us-east-1 --auto-scaling-group-names gpu-fast-lane
aws autoscaling set-desired-capacity --region us-east-1 --auto-scaling-group-name gpu-fast-lane --desired-capacity 6000

# 4. Move dead-letter messages back to their source queue after a fix
aws sqs start-message-move-task --region us-east-1 --source-arn arn:aws:sqs:us-east-1:123456789012:transcode-fast-dlq

# 5. Workflows still running
aws stepfunctions list-executions --region us-east-1 --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:vod-pipeline --status-filter RUNNING --max-items 50

# 6. CloudFront error rate (CloudFront metrics live in us-east-1 with Region=Global)
aws cloudwatch get-metric-statistics --region us-east-1 --namespace AWS/CloudFront --metric-name 5xxErrorRate --dimensions Name=DistributionId,Value=E2ABC123EXAMPLE Name=Region,Value=Global --start-time 2026-10-05T09:00:00Z --end-time 2026-10-05T09:30:00Z --period 60 --statistics Average

# 7. Invalidate everything tagged with a video, then track it
aws cloudfront create-invalidation --distribution-id E2ABC123EXAMPLE --paths "#vid:v_Q2x9"
aws cloudfront get-invalidation --distribution-id E2ABC123EXAMPLE --id I2J0I21PCUYOIK

# 8. Add a video to the CloudFront emergency blocklist (needs the store's current ETag)
aws cloudfront-keyvaluestore describe-key-value-store --kvs-arn arn:aws:cloudfront::123456789012:key-value-store/0f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b
aws cloudfront-keyvaluestore put-key --kvs-arn arn:aws:cloudfront::123456789012:key-value-store/0f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b --key v_Q2x9 --value block --if-match ETVPDKIKX0DER

# 9. Live channel state for the final
aws medialive describe-channel --region eu-west-1 --channel-id 1234567

# 10. Deploy the steering document (weights, caps)
aws appconfig start-deployment --region us-east-1 --application-id abc1234 --environment-id def5678 --deployment-strategy-id AppConfig.AllAtOnce --configuration-profile-id ghi9012 --configuration-version 43

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Builds live as a continuous pipeline, adds up the glass-to-glass latency, and offers modes instead of one answer.
• Treats CDNs as interchangeable suppliers: steering from real measurements, player-side failover, keep-alive steering documents, and identical rules at every one.
• Proves the design survives losing its largest CDN during the biggest event, with numbers.
• Knows why hashes don't find copies, and makes matching robust and reversible.
• Puts availability rules in a separate, append-only layer that survives every update, restore and failover, and takes it down through every cache.
• Is honest about what "deleted" means while backups exist.
• Cuts cost with levers whose assumptions are labeled, finds that software alone lands at −29%, and knows what closes the gap.

Follow-up questions

1. "Why not make every stream low latency?" Answer: 4 requests a second per viewer instead of 1, and a 1.5 s buffer instead of 6 s, so more stalls on weak networks. For the final, with 30% in low latency, that's 19M requests a second instead of 10M. Low latency is worth it where spoilers matter, not for a cooking stream.

2. "A country orders a video blocked, and a week later the creator re-uploads it as a new video." Answer: the restriction is on the old video ID, so the new one isn't blocked by it. The legal team can ask for the ruling to cover copies; then we add the blocked video's fingerprints as a reference with a block policy for that country, and the matcher catches re-uploads before they publish.

3. "Why do other CDNs pull through CloudFront's Origin Shield? Isn't that a dependency on one vendor?" Answer: it is, and we accept it for the common case because it collapses origin requests across all CDNs into one. The other CDNs keep a direct origin path, behind a secret header, for when CloudFront is the problem.

Interview gotchas from this round's wrong answers

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint. For blob storage internals, see the S3 object storage loop; for live chat beside a stream, the chat loop.

The Two Sentences That Matter Most

• Opening any round: "Video is a bytes-and-money problem: I'll keep every byte out of our servers, turn each upload into a ladder of segmented renditions the player can switch between, and let CDNs serve the bytes, because delivery will be most of the bill."
• When scale arrives: "I'll transcode in parallel keyframe-aligned chunks on Spot GPUs with idempotent tasks, protect the origin with a shield, count views through a stream with conditional writes, and then attack cost per view-hour where it actually lives: bytes per view and who carries them."

Well-Architected Review Sheet

Interviewers rarely ask "which pillar is this?". They ask the pillar's question in plain words. Rehearse one sentence per row.

Rubric Across Levels