Technical Interview: Architecture Section

The host of the main studio, Alexander Voronkov, opens the session: the day before the conference ran the algorithms round, today architecture. The interviewer is Alexander Polomodov, who has spent almost six years leading one of the directions at his company and curating how its system design interviews are run. The candidate is Vladimir Ivanov: about nine years at 2GIS, the last five building a cross-platform C++ mobile application, with no high-load backends in his day job — which, he says himself, should only make it more interesting. Alexander states the format up front: design iteratively, from something simple towards complexity, ask questions at any moment. He plays two roles — answering clarifying questions about how the system will be used, and acting as a technical engineer who discusses the proposals with the candidate. Vladimir restates the brief in his own words: a stripped-down YouTube. The interviewer agrees.

The requirements sit on the screen, and Vladimir starts with numbers. Ten million users a day; one in ten uploads a single video daily; everyone watches about ten; an average subscription list of a hundred channels. The subscription graph is declared uniform and super-popular channels are excluded for now: the candidate remembered them almost immediately, the interviewer marked that as a good move but parked the topic for the end so the main part fits. Content limits: a gigabyte per file, four quality levels including 480, and the top ones simply do not exist when the source is poor. Users are assumed to be spread across time zones. Scope was drawn quickly: the client side stays outside, the design covers the public backend API, and how mobile developers consume it is their problem. Analytics, monitoring, legal questions, authentication and authorization were dropped: the model task is trimmed on purpose so it can be discussed properly within an hour. Storing subscriptions is an external service; the assembled feed belongs to the system under design.

Vladimir starts from a blank sheet and the upload scenario. The user brings a fat file, and nobody intends to push it in one piece: the answer is an operation like create a file and keep appending data to it, so that the receiving endpoint does not accumulate hundreds of megabytes in memory. The candidate admits he is not closely familiar with object storage. Next come a metadata store tying the uploaded file to its author, a separate place for the compressed videos, and a compressor that prepares every resolution. A video counts as ready once all resolutions are there: reality does not work like that, but for a model task the concept holds, and nobody wants to start serving 4K before the rest is done. The interviewer slows the candidate down on the public upload endpoint — too many arrows already leave it, and that looks suspicious. Vladimir takes a minute's pause and proposes splitting the component, separating the intake of the file from what happens to the video afterwards.

Feeds are assembled on write. The moment a video is ready, its id is fanned out into the feeds of all subscribers: a user will not wait for a feed built at read time, and it would be sad to ask for new videos from your subscriptions and wait. The candidate sees the feed itself as a key-value store mapping a user to his feed, though a plain relational table would do too; in the model task the attributes left are a title and a thumbnail. Hence the fork the interviewer highlights: either denormalize the title and the links to every resolution into the feed and then be unable to do anything else with them, or keep them in the database and stitch them in on read. A load estimate: if the feed is opened about five times a day, that gives roughly fifty million requests, and it is easier to divide by a round hundred thousand seconds than by 86,400. Sharding the feed by user id works out of the box, and the only thing that breaks it is unusually active accounts you would rather not land in one shard.

Two decisions get a detailed treatment. The first is the CDN, which the candidate describes with its dumbest possible scheme: caching nodes that fetch a file once and serve it themselves afterwards. In front of them Vladimir wants an endpoint handing out a link to the video, and the interviewer objects: such a component has no responsibility of its own, the link can be composed by the feed in its response, the CDN itself will route the client to the nearest point, and an intermediate request forces the client to travel twice — first for the link, then for the video. The second is the link between the compressor and the database: the candidate proposed periodically selecting videos that carry no compressed flag, and called the idea mediocre himself. The interviewer agrees — that is a queue assembled out of a database, with a status model and periodic polling, workable at a certain scale but a leftover — and explains the difference between a task queue, where a finished task disappears, blocks nobody, and many compressors take independent tasks in parallel, and a log of events, where commit semantics are trickier.

Originals are useless after compression, yet deleting them with a single call from the compressor is risky: the deletion task can get lost, and without an external garbage collector and a database record you cannot tell what went missing. Here the time runs out, and Alexander turns to his notes: he tries to put the file on screen, it does not download in time, the debrief starts aloud, and the picture goes up partway through. There is a scoring matrix for candidates, but the spider chart inside it is never drawn — a table is easier to read, and from short marks with arrows and pluses the interviewer later reconstructs the conversation. The verdict: formalizing the requirements went well, the load questions were the right ones to ask, and the question about system boundaries and the client side was a good one. Some of the clarifying questions, Alexander admits, he had not asked himself when he solved this task, and that counts as a big plus. Overall: strong at the conceptual stages, weaker on concrete choices, but knowledgeable enough for a cross-functional team.