Design a Video Streaming Service: DRM, Live, Failure Modes and Cost (2026)

The interviewer nods at your pipeline and says: “Good. Now your CDNCDN: a network of cache servers close to viewers, so common files are served from nearby has an outage at peak. And the studio wants this protected. And a premiere goes live at 8 pm.”

That is the second half of a streaming round. Drawing the pipeline is the first half. These follow-ups show whether you have thought about running it, and most answers lean on one fact from the main lesson: segments never change, so almost everything can be cached, and everything personal is small.

What Breaks, and What Saves You#

Start with failures, because the design was built around them. “Judgement” means design opinion, not a vendor’s documented behaviour.

Which Failures Do Viewers Feel?#

A running player holds seconds of video and the manifest, so the CDN, origin and API can fail for a short time without a stall. New starts feel everything. That is why start-time and failure rate are tracked apart from stall time, as the QoE section shows. Say it plainly: a failure costs new starts first, and running sessions later.

What Happens at a Premiere?#

At 8 pm a hit title goes live. Assume 1.25 million viewers (the main lesson’s peak) press play within a minute. Every one asks for the same first segment and the same manifest. Every cache is cold for that title.

• Works: Let the CDN sort it out. Each miss goes to origin. In the worst case that is up to 1.25 million requests for one object in one second. Trade-off: the origin falls over, and the CDN’s retries make it worse.
• Scales: Collapse requests at each tier. Request collapsing (also called coalescing) makes a cache hold waiting requests for an object that is already being fetched and answer them all from one upstream fetch. With an assumed 1,000 edge sites, origin sees about 1,000 requests per segment per rung. With 10 shield caches in between, it sees about 10. Trade-off: waiting viewers add a little latency, and a stuck fetch can stall them all, so set a timeout.
• Survives: Fill before release time. Netflix says it can predict what members will watch and push most content to caches in off-peak fill windows. Copy the idea (judgement for other services): finish transcoding early, keep the video in a “ready, not yet released” state, copy it to shields and edges ahead of time, and publish the manifest at release time. Origin sees nothing. Trade-off: it needs a known release time, and it fills caches for titles that may not become popular, so use it for tentpoles only.

What About Everything That Is Not a Segment?#

Segments are only one of three stampedes. The manifest can be cached for a second or two at the edge. The playback API takes about that many calls (assumed), so scale it out and rate limit with 429 and a retry-after, as in the rate limiter lesson. The licence server is the hard one, because licences cannot be shared: the next section explains why.

How Does DRM Work?#

DRMDRM: digital rights management, technology that encrypts content and releases the key only to approved players keeps a copy of a segment from being played by anyone without a key. It does not stop someone filming a screen. Studios often require it, so expect the question.

1. Encrypt once. Segments are encrypted with a content key before they reach the CDN. They stay encrypted and fully cacheable.
2. Ask for a licence. The player reads the key id from the manifest and sends a licence request. In browsers, Encrypted Media Extensions let the page pass that message between the decryption module and your server. EME defines no DRM itself.
3. Check rights. A licence proxy that you run checks login, plan, region and device, then forwards the request to the DRM licence server. Widevine’s docs say its client never talks directly to the licence service, and that licences are individualised to the requesting device.
4. Decrypt on the device. The key stays inside the device’s decryption module and the picture is shown.

Which Systems, and How Many Copies?#

The encryption scheme matters more than the vendor. DASH-IF says cenc and cbcs are two mutually exclusive schemes: content encrypted with one cannot be decrypted by a system that supports only the other. Encrypt one cbcs copy for current devices, and keep a cenc copy only if you still serve old Android versions (Widevine lists cbcs from Android 7). That keeps storage near one copy instead of three.

Without a studio requirement, HLS also offers simple AES-128 encryption with a key URI that must be delivered over TLS. That raises the bar for casual copying, but it is not DRM, and the key is only as safe as your token.

What Changes for Live?#

On demand, every segment exists before anyone asks. Live creates the next segment every few seconds, and viewers sit as close to the edge as the format allows.

The first two rows come from RFC 8216: a client should not start less than three target durations from the end of the playlist, so 3 × 6 s = 18 s and 3 × 2 s = 6 s, before encode, upload and CDN time. A live playlist must also gain a new version within 1.5 target durations, so viewers keep reloading it.

Low-latency HLS is defined in an IETF draft with three parts:

• Partial segments, published before their parent segment is complete. The server must add a new part within one part target duration.
• Blocking playlist reload, where the server holds a request until the part exists.
• Preload hints, so the player can ask for a part before it is ready.

WebRTC is the other route. WHIP (RFC 9725) standardises sending media into a service over WebRTC with one HTTP exchange. For viewers it needs live connections, so use it where latency is the product, such as auctions or sports betting.

What Does Live Do to the CDN?#

Assume 1 million live viewers on 2 second segments. Each reloads the playlist about every 2 seconds, so the playlist alone draws about 500,000 requests a second, and segments add as many more (assumption). Cache playlists for a fraction of a target duration and collapse requests, or the origin sees about a million requests a second (assumed load). Shorter segments cut delay and multiply this load, so state which one the product needs.

How Do You Know Viewers Are Happy?#

Measure what the viewer feels, from the player, not from the servers.

A 10 minute session with three 2 second stalls has 6 ÷ 600 = 1.0% rebuffer ratio, which would miss this target. The Netflix and Stanford buffer-based paper judged players on rebuffer rate and video rate, and Open Connect’s control plane stores playback telemetry. Players send small beacons; sample them to bound the volume.

SLOsSLO: service level objective, a target such as 99.9% of plays starting within two seconds need an error budget. A 99.95% playback API over 30 days allows 43,200 minutes × 0.0005 ≈ 21.6 minutes of failure. Slice every metric by CDN, ISP, device and region, because the useful alert is “start failures on CDN B in one ISP doubled”, not a global average. When one path degrades, steer new sessions away from it.

What Does It Cost?#

Assume these illustrative unit prices, not quotes: egress $0.01 per GB, hot storage $0.02 per GB-month, cold storage $0.004 per GB-month, compute $0.04 per core-hour. Check your own contracts. The loads are the main lesson’s assumptions.

Three conclusions. Delivery dominates a busy day, but storage overtakes it when unwatched titles pile up, so tier cold titles and stage renditions. Assume keeping only the three lowest rungs (2.7 of 11.7 Mbit/s, 23%) for 90% of titles: that cuts bytes by about 69%. Caches inside ISPs cut egress, which is why Netflix offers them free to qualifying ISPs. Encoding is the small line, but a codec decision multiplies it.

When Does a Better Codec Pay Off?#

Assume AV1 saves 30% of delivered bits and costs 5 times the encode compute of H.264. Both are assumptions to be measured.

• Assume encoding one hour of video into the ladder costs 2.5 core-hours × $0.04 = $0.10, so AV1 adds $0.40.
• Assume one viewing hour is 1.5 Mbit/s × 3,600 s = 0.675 GB, which costs $0.00675 to deliver, so 30% saves about $0.002.
• Break-even is $0.40 ÷ $0.002 ≈ 200 viewing hours per hour of video.

Popular titles pass that quickly, and the long tail never does, so make newer-codec rungs a popularity-gated stage, as the main lesson’s staged encoding does. Hardware encoders are faster and cheaper per hour but compress less well (judgement).

What About Regions and Disasters?#

Separate originals from derived data:

• The uploaded original is the source of truth.
• Every rendition can be rebuilt from it, at the compute cost above.
• So replicate originals everywhere, and popular segments selectively.

Replicating all 527 TB of daily renditions is 527 × 10^12 × 8 ÷ 86,400 ≈ 49 Gbit/s. S3 Replication Time Control has a default quota of 1 Gbps, so you would need an increase or selective copying.

S3’s replication time control copies most objects in seconds and 99.9% within 15 minutes, so a title may reach region B after its manifest does. Serve manifests only for titles whose objects have arrived. Use two CDNs, and keep the playback API, metadata and licence service in at least two regions.

How Do You Fight Piracy and Handle Takedowns?#

• Tokens. Segment URLs carry signed, short-lived tokens, so a link cannot be shared for long and hotlinking fails (judgement).
• DRM on premium titles, as above, and per-session limits on concurrent streams.
• Upload checks. Scan uploads for malware and policy violations in a worker before publishing, and match known works by fingerprint (judgement, no source read).
• Takedown. US law, 17 U.S.C. section 512, conditions its safe harbour on acting expeditiously to remove or disable access after a valid notice, restoring material 10 to 14 business days after a valid counter-notice unless the claimant sues, and having a repeat-infringer policy. This is a summary of the statute, not legal advice.

Design for it: a blocked status makes the playback API refuse, manifests stop being issued, and a purge request goes to the CDNs. Segments are cached for a long time, but without a manifest and a valid token nobody can reach them.

Follow-ups Interviewers Add#

Short answers. “Judgement” marks opinion, not a vendor’s behaviour.

A 45-Minute Plan#

 5 min  questions, assumptions
 5 min  numbers and API
10 min  simple design, limits
15 min  ladder, player, CDN
 5 min  failures, DRM or live
 5 min  QoE, cost, follow-ups

Pick DRM or live by what the interviewer asks. If time is short, spend the last five minutes on the failure table and offer one more topic to choose from.

Red Flags and Green Flags#

At staff level, expect a stated recommendation for each trade-off, a cost model with named assumptions, and an answer to “what do you build first?” (the segmented pipeline and one CDN, then QoE telemetry, then DRM).

Try It: A Premiere at 8 pm#

Licences: 1,250,000 / 60
  ≈ 20,800 requests/s
Origin, one rung, one segment:
  none:    up to 1,250,000
  edges:   1,000
  shields: 10

Check Yourself#

In One Picture#

Failures
  buffer + retry + 2nd CDN
Premiere
  fill, collapse, shield
DRM
  encrypt once, licence personal
Live
  3 x segment behind live
QoE
  start, rebuffer, failures
Cost
  egress, storage, codec
Rule
  cacheable big, cheap personal

Conclusion#

The 60-second follow-up answer: a running player survives most failures on its buffer and a second CDN. A premiere is a stampede, so fill caches early and collapse requests. DRM adds a small personal licence request that cannot be cached. Live trades cache hits for latency. Measure start time, rebuffer ratio and failures by CDN and ISP, and price egress, storage and codecs with stated assumptions.

Which follow-up has caught you out before? Tell us in the comments.