A reliable video processing pipeline
Design a Video Processing Pipeline, from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
A course platform lets instructors upload lecture recordings. Files are usually 200 MB to 4 GB, recorded on laptops and uploaded over home or café connections. Each upload has to become an adaptive-bitrate stream (1080p, 720p and 480p renditions) plus a thumbnail before students can watch it.
The prototype is an Express server that accepts a multipart form upload to local disk and runs ffmpeg inside the request handler. It worked for the ten test videos. The platform launches next month at around 2,000 uploads a day, with Sunday evenings running at five times the average rate.
You own the pipeline from "instructor selects a file" to "student presses play". Nothing about the prototype is sacred.
What the interviewer would tell you if you asked
- About 2,000 uploads a day at launch, peaking at 5x the average on Sunday evenings; 10x growth expected within a year.
- A transcode takes 5-20 minutes of CPU (about 12.5 on average); one worker runs one transcode at a time.
- API servers are stateless containers behind a load balancer with a 60-second request timeout, redeployed several times a day.
- Small team: managed infrastructure is preferred, and one Postgres database already exists.
- An object store with S3-like semantics is available: durable writes, presigned URLs, multipart uploads, and read-after-write consistency for new objects.
- Instructors' browsers can upload to the object store directly over HTTPS.
- Transcoding the same input twice produces equivalent output.
- Postgres is the system of record; losing it is a disaster-recovery event, not a design input.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.