A stripped-down YouTube and where the task stops
The brief was a stripped-down YouTube: upload a video, watch it, and see a feed from the channels you follow, with subscribers notified about new uploads. The candidate pinned down numbers early — ten million daily users, one in ten uploading a single video a day, everyone watching about ten, an average subscription list of a hundred channels. Files cap at one gigabyte, four quality levels are offered including 480, and the top ones simply do not exist when the source is poor.
Scope was cut just as fast. The client side stays outside: what gets designed is the public backend API, and how mobile developers consume it remains their problem. Analytics, monitoring, legal questions, authentication and authorization were all dropped, with the interviewer saying plainly that the model task is trimmed on purpose so it can be discussed properly within an hour. The subscription graph was declared an external service, while the assembled feed stayed inside the system under design.
From an uploaded file to a subscriber's feed
The diagram grew in passes. The user pushes a file in chunks into object storage, a compressor picks up the original, produces every resolution and stores the results apart from the source; a video counts as ready once all resolutions exist. A metadata store ties the uploaded file to its author, and feeds are built on write: the moment a video is ready, its id is fanned out into the timelines of all subscribers, because nobody will wait for a feed assembled at read time.
A quick estimate: if each user refreshes the feed about five times a day, that gives roughly fifty million feed requests, and it is easier to divide by a round hundred thousand seconds than by 86,400. The CDN produced the one real disagreement. The candidate wanted a service in front of it handing out video links; the interviewer argued that such a component has no responsibility of its own — the link can be composed inside the feed response, and routing to the nearest edge is the CDN's own job.
Where the interviewer saw the soft spots
The main critique landed on the link between the compressor and the database. The candidate proposed periodically selecting videos that carry no compressed flag and pulling them into work, calling the idea mediocre himself. The interviewer agreed: that is a queue assembled out of a database, with a status model and periodic polling — it does work at a certain scale, but stays a leftover. A message broker fits better, letting many compressors take independent tasks in parallel, where a finished task simply disappears and blocks nobody.
Then came details that reveal experience. Originals are useless after compression, yet deleting them from the compressor alone is risky: without an external garbage collector and a record in the database you cannot tell what went missing along the way. Sharding timelines by user id works out of the box and only breaks on unusually active accounts. The super-popular-channel problem was parked for the end and never reached. The verdict: strong at the conceptual level, weaker on concrete choices, but good enough for a mobile engineer to hold his own in a cross-functional team.
What to take away
- 01Task parameters are chosen so that something pinches — data volume, request rate, or a genuinely awkward process; otherwise there is nothing left to improve.
- 02Polling a table by a status flag is a queue assembled from the wrong parts; a broker gives parallel processing of independent tasks instead.
- 03A component with no responsibility of its own is dead weight — the CDN link can simply travel inside the feed response.
- 04Drawing boxes is not enough: the interviewer waits for a coherent retelling of how data crosses the system from the public endpoint to the result on screen.
Sources
- Automatic captions from the recording
- Interview recording