Loading…
Scale a Web Application from Thousands to Millions of Users is a medium cloud architecture interview question covering cloud architecture, autoscaling, caching, managed services, cdn — the kind asked at FAANG (Facebook/Meta, Apple, Amazon, Netflix, Google) and AI-first companies like Anthropic, OpenAI, and Nvidia.
An existing application - part static marketing pages, part logged-in personalised content - runs on a handful of servers with sessions held in application memory. A campaign is about to increase traffic by one to two orders of magnitude, arriving as a spike rather than a ramp. Keep it fast and available. Work across the whole stack, not just the database.
That's it. No further details. This is intentional — your first job is to scope the problem by asking the right clarifying questions.
A deliberately broad question, and the breadth is the test. An existing application — part static marketing pages, part logged-in dynamic content — currently serves a modest audience from a small number of servers, and is about to grow its traffic by one to two orders of magnitude. The interviewer is checking whether you can hold a whole stack in your head at once rather than optimising the layer you happen to know best. Candidates who go straight to database sharding are answering a question that has not been asked yet; the first order of business is to find out which layer actually breaks first, and the answer is very often the one nobody mentions. Strong candidates work outside in, quantify before optimising, and separate the changes that buy an order of magnitude for very little effort from the ones that are expensive and can wait.
Work through the Clarify phase by asking questions one at a time — just like a real interview.
Each answer reveals why that question matters and how it changes your design decisions.
Once you've clarified enough, unlock the full architecture, the managed-versus-self-run reasoning, and the trade-off analysis.
Design rounds are decided on capacity estimates. Both tools are free.
Work outside in, because each layer removes load from the one behind it and outer layers are far cheaper to change. First establish the traffic mix: if roughly eighty percent of page views are anonymous and identical for everyone, they can be cached at the edge and never reach the origin, which turns a two-hundred-request-per-second problem into a fifty-request-per-second one. That single change absorbs most of the growth. Second, find the hidden blocker - sessions in application server memory with sticky routing make horizontal scaling impossible, because a server cannot be removed without logging its users out and every deploy is a mass logout. Externalising sessions is a prerequisite for everything else, not an optimisation. Then: stateless app servers behind a load balancer with autoscaling, a shared cache for hot rows and computed results, read replicas for a read-heavy workload, and a queue for anything not needed before the response is sent - email, thumbnails, exports, third-party calls - which also isolates a slow dependency from taking down unrelated pages. Order the database work from cheapest to most disruptive: fix queries and indexes, add memory, add read replicas, and only partition when writes genuinely exceed one primary. Explicitly defer sharding. On the spike, note that autoscaling reacts in minutes and a spike can arrive faster, so pre-provision for a known campaign and load test to a breaking point beforehand. Do not decompose into services during a traffic spike - that converts a capacity problem into a distributed systems problem at the worst possible moment.
A full interview loop is more than one round. These are the others, each with what is on the site for it.