Design the Transcoding System

The live video pipeline lesson walked the whole path from a broadcaster's encoder to a viewer's player. One box in that path did the heavy lifting: the origin that turns a single incoming stream into several renditions the player can switch between. This lesson pulls that box out and treats the fleet behind it as its own design. Interviewers do this on purpose. The end-to-end pipeline is where you show breadth, and the transcode fleet is where they check whether you can go deep on a genuinely hard resource-scheduling problem.

What makes it hard is that live transcoding is unforgiving in a way most batch jobs are not. Encoding a movie file for a video-on-demand library is embarrassingly parallel and can take its time: chop it into chunks, encode them on any spare machine, stitch the result back together. A live stream has none of that slack. It arrives as a continuous feed. It has to be encoded as fast as it plays for the whole broadcast, and there is no chunk to hand off later. One worker owns a stream for its whole life. Fall even a second behind real time and viewers see a stall. So the fleet is a real-time scheduling problem: place each stream on a healthy worker, keep every worker inside its capacity, and never let a broadcast go dark.

The Twitch angle

The distinctive move here is treating live transcode as a continuous per-stream commitment, not a queue of jobs a worker pool drains at its own pace. Twitch built its own transcoder rather than shipping stock FFmpeg precisely so it could own the full ingest-to-playback path and tune the encode for live. A strong answer names that continuity early. One stream pins one worker for the whole broadcast. The work cannot be deferred or retried later the way a video-on-demand encode can, and the capacity you provision has to cover the peak of concurrent live channels, not the average. The round runs on Amazon's machinery, so expect the interviewer to press Dive Deep here.