Video, transcoding, DRM, and the CDN decider
The video stack in one page — and the decision framework for "how much of this do I build?"
Concept → your projects
The video pipeline (the canonical stages):
- Ingest: direct-to-storage multipart upload (Day 79) → a job queued (your notification outbox pattern generalizes: upload complete → event → worker).
- Transcode: split into segments, encode a bitrate ladder (e.g. 240p/480p/720p/1080p × H.264/AV1), package (HLS:
.m3u8playlists +.ts/.fmp4segments; DASH for the open standard) — CPU-heavy, embarrassingly parallel, ideal for spot/preemptible workers with checkpointing. - Store + distribute: segments to object storage → CDN in front. Adaptive bitrate (ABR) is the client's job: it measures bandwidth/buffer and switches the next segment's rendition — so the playlist must contain all renditions with bandwidth metadata, and segment boundaries must align across renditions (same keyframe cadence) or switching breaks.
- Play: player fetches playlist → picks rendition → fetches segments ahead → buffer management is the whole game (startup latency vs. rebuffering).
The CDN decider (your topic list's phrase): where to serve from — origin only (small audience, single region), CDN pull (default; caches on demand, cheap), CDN push/pre-warm (launches, known virality), or multi-CDN with traffic steering (global reach, resilience — complex, expensive). The deciding inputs: audience geography, egress cost, cache-hit ratio targets, and latency SLOs. For a personal project: object storage + a pull CDN is the answer; multi-CDN is a company-sized problem.
Signed URLs, DRM, and security: access control levels — public, signed URL/cookie (time-bound, IP/referrer-restricted), token-based CDN auth (short-lived per-session tokens), and DRM (Widevine/PlayReady/FairPlay) which is content encryption + license servers (a whole business, not a checkbox). The honest ladder: signed URLs stop casual sharing; DRM stops determined extraction; nothing stops screen recording. Pick the level the business requires — most products need signed URLs only.
Live streaming / WebRTC / latency: RTMP/SRT ingest → transcode → HLS (5–30 s latency) or LL-HLS/DASH (2–5 s) or WebRTC (sub-500 ms, but peer/relay-heavy and not built for 1-to-many scale without an SFU). Latency classes: interactive (WebRTC, <500 ms), near-live (LL-HLS, 2–5 s), standard (HLS, 10–30 s). Choose by interaction requirement — sports betting needs near-live; a webinar doesn't.
Your systems' position (and the honest answer)
No video anywhere — and the framework answer is what scores: "If traverse ever needed submission-recording playback, the pipeline is: presigned multipart upload → BullMQ transcode jobs (spot workers, checkpointed per segment) → HLS ladder in S3 → CDN with signed cookies → ABR player. I'd build the ladder for two renditions, not seven — the cost/benefit of each additional rendition is measurable in storage and encode time. DRM I'd skip entirely: user recordings aren't studio content; signed URLs cover the access requirement." Sizing the build instead of reciting the architecture is the differentiator.
Bulletproof your resume
Say these answers aloud before moving on
These are the follow-ups an interviewer will actually ask about your projects.
Explain adaptive bitrate in one paragraph.
The player maintains a buffer and estimates throughput; from the HLS/DASH manifest it picks the next segment's rendition (low bitrate when the network is poor, high when healthy), so quality degrades gracefully instead of stalling. Requirements that make it work: aligned segment boundaries and keyframes across renditions (so switching is seamless), bandwidth metadata in the playlist, and a startup strategy (begin at a mid rendition, ramp up — or begin low for fast start, ramp quickly). Rebuffering hurts users far more than lower resolution, which is why the algorithms optimize for buffer health over quality.
What latency can you get from each streaming approach?
HLS/DASH standard: 10–30 s (multi-segment buffering). Low-latency HLS/DASH: 2–5 s (partial segments, chunked transfer). WebRTC: sub-500 ms (UDP-based, no buffering by design) but needs an SFU to scale beyond small audiences and loses the CDN's caching economics. Interactive classes (bidding, gaming, live auctions) require WebRTC; a webinar or VOD is better served by the CDN-cached HLS path — paying for latency you don't need is the common mistake.
Do you need DRM?
Almost never for user-generated or internal content: signed URLs + token auth cover the real requirement (time-bound, authorized access). DRM (Widevine/FairPlay/PlayReady + license servers) is for licensed commercial content where the threat model includes determined extraction and the contracts demand it — it adds a license infrastructure, device compatibility matrices, and cost, and it still can't stop screen recording. The ladder I'd apply: public → signed URLs → token auth → DRM, stopping at the first level that satisfies the actual threat model.