Design a video platformSystem design interview practice, out loud
A voice interviewer that follows your reasoning, on a canvas you both see. Here is the brief, the numbers you can ask for, and what the interview goes into.
- System design
- 30 or 45 minutes
- Suggested for Mid, Senior and Staff, open at every level
Private beta · 30 free minutes when you're in
A desktop browser and a microphone.
The brief
The interviewer reads it out, then waits for you.
“Design a video platform. People upload a video from a phone or a laptop, and anyone can watch it — on a slow connection, on a TV, anywhere in the world. Each video shows a view count under it. Start wherever you like; the canvas is yours.”
The numbers you can ask for
The interviewer answers these when you ask, and never volunteers them. For anything else it says the brief doesn't fix that: choose an assumption and say it out loud.
| You ask | The interviewer answers |
|---|---|
| How many viewers? | 500 M people watch on a given day |
| How many views? | 5 B views/day; average ≈ 58 k/s, peak 3× |
| How much upload? | ~1 M videos/day |
| How long is a video? | 10 minutes on average; the long tail runs to hours |
| How big is the source file? | ~1 GB for 10 minutes at 1080p |
| Read/write ratio? | ~5000 views per upload |
| How fast must playback start? | First frame under 1 s, p95 under 2 s |
| Rebuffering budget? | Under 0.5 % of watch time |
| Where are the viewers? | Global; most traffic US, EU, India |
| Availability? | Playback 99.95 %, upload 99.9 % |
| Retention? | Videos are kept indefinitely; no deletion policy needed |
| Is X in scope? | In: upload, processing, storage, playback, view count. Out: recommendations, search, comments, live streaming, monetisation, DRM, moderation |
| Budget? | Egress dominates the bill; treat cost as a real constraint |
Be ready for these
The interviewer starts with the requirements and ends with the wrap-up. In between, it follows you, so the order is yours. The answers are yours too: this page doesn't give them.
- What exactly are you building, and what numbers must it hold?First
- How do the bytes get from the device to storage?
- How does the uploaded file become something every viewer can play?
- Where do the bytes and the records live, and how do they grow?If there's time
- How does the first frame reach a viewer anywhere, fast?
- How are views counted, and how is the watch page served?
- Where is your design weakest, and what would you build first?Last
- Can someone follow your canvas without you there to explain it?Throughout
What's expected at your level
Your Report reads you against the bar for the level you pick. Each level keeps what's below it and adds a line.
See all twelve bars →At Junior
- Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
- Turns one given number into a new figure, out loud, and uses a number to justify one choice.
- Treats reads and writes as separate paths, and says which one is busier.
- Judged only if the interviewer asks about it, at Junior.
- Says what happens when a named part fails, and one way the system recovers.
- Judged only if the interviewer asks about it, at Junior.
Not judged at Junior.
- Names an alternative to one choice, and a reason tied to the problem.
- On the final canvas, every box is named and joined to its flow.
At Mid
- Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
- +Names something that is out, and sizes the reads and the writes separately.
- Turns one given number into a new figure, out loud, and uses a number to justify one choice.
- +Says the unit, and uses a figure they worked out to size a named component.
- Treats reads and writes as separate paths, and says which one is busier.
- +Says how the busier path scales out.
- Says what happens when a named part fails, and one way the system recovers.
- +Says what happens to the work in flight, and a concrete limit on the recovery.
- Says which work happens later and what starts it, and what the user is told, and when.
- Names an alternative to one choice, and a reason tied to the problem.
- +Gives a reason specific to this system, and names what their own pick costs.
- On the final canvas, every box is named and joined to its flow.
- +Talks while drawing: names each box as it goes down.
At Senior
- Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
- +Names something that is out, and sizes the reads and the writes separately.
- +Sets a target (a latency, an availability) and names the part of the design it constrains.
- Turns one given number into a new figure, out loud, and uses a number to justify one choice.
- +Says the unit, and uses a figure they worked out to size a named component.
- +Sizes both sides: a figure for the writes and a figure for the reads.
- Treats reads and writes as separate paths, and says which one is busier.
- +Says how the busier path scales out.
- +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
- Says what happens when a named part fails, and one way the system recovers.
- +Says what happens to the work in flight, and a concrete limit on the recovery.
- +Handles a second failure, in a different part of the design.
- Says which work happens later and what starts it, and what the user is told, and when.
- +Says how the client learns the work finished, or how stale a value may be.
- Names an alternative to one choice, and a reason tied to the problem.
- +Gives a reason specific to this system, and names what their own pick costs.
- +Says when their choice would stop being right, and what they would change then.
- On the final canvas, every box is named and joined to its flow.
- +Talks while drawing: names each box as it goes down.
- +Walks the whole design once, near the end.
At Staff
- Before drawing, says one thing the system must do, and one assumption about who uses it or how much.
- +Names something that is out, and sizes the reads and the writes separately.
- +Sets a target (a latency, an availability) and names the part of the design it constrains.
- +Names the requirement that would change the architecture, and what would change.
- Turns one given number into a new figure, out loud, and uses a number to justify one choice.
- +Says the unit, and uses a figure they worked out to size a named component.
- +Sizes both sides: a figure for the writes and a figure for the reads.
- +Names the figure that limits the design, and says why.
- Treats reads and writes as separate paths, and says which one is busier.
- +Says how the busier path scales out.
- +Puts a cache or a CDN on the busy path and says what it holds, or shows none is needed.
- +Names what fails first at ten times the load, and the fix.
- Says what happens when a named part fails, and one way the system recovers.
- +Says what happens to the work in flight, and a concrete limit on the recovery.
- +Handles a second failure, in a different part of the design.
- +Says how a failure is kept from spreading, and what keeps working meanwhile.
- Says which work happens later and what starts it, and what the user is told, and when.
- +Says how the client learns the work finished, or how stale a value may be.
- +Says what happens when that work fails or runs twice.
- Names an alternative to one choice, and a reason tied to the problem.
- +Gives a reason specific to this system, and names what their own pick costs.
- +Says when their choice would stop being right, and what they would change then.
- +Names the decision that is hardest to reverse, and why.
- On the final canvas, every box is named and joined to its flow.
- +Talks while drawing: names each box as it goes down.
- +Walks the whole design once, near the end.
- +Answers each question in its first sentence, then gives the detail.
Thirty minutes. Out loud. On this brief.
Pick your level when you start. Pause for coaching if you get stuck, and read your Report a few minutes after.
Private beta · 30 free minutes when you're in