The system design interview

Estimation is arithmetic done out loud, and the numbers to memorise are few. A day is 86,400 seconds, near enough 100,000. So a million events a day is about 12 a second, and a billion is about 12,000 a second. Peak is commonly two to three times average, and traffic is never spread evenly across the day.

Storage follows the same shape. A thousand bytes per record at a million records a day is a gigabyte a day, roughly a third of a terabyte a year. A million users with a kilobyte of profile each is a gigabyte in total, which is a laptop rather than a cluster and worth saying so plainly when someone proposes sharding it.

A few latency numbers anchor everything else and are worth knowing to an order of magnitude: memory access in tens of nanoseconds, an SSD read in tens of microseconds, a data centre round trip around half a millisecond, and a cross-continental round trip well over a hundred milliseconds. Those are the ratios behind almost every caching and placement decision you will ever justify.

Round aggressively and say that you are. Use 100,000 seconds for a day, treat a kilobyte as a thousand bytes, call a month thirty days. Nobody is checking your arithmetic, and precision is the enemy of finishing the calculation in the ninety seconds it deserves.

The point is not accuracy but the class of system. Twelve requests a second is one server and no discussion. Twelve thousand is a fleet, a cache and a real conversation about the data layer. Being twenty per cent out changes nothing; being out by a factor of a thousand invalidates every design decision that follows, which is the failure the exercise exists to prevent. Sanity-check the answer against something you know. If your estimate implies more storage than a large public dataset, or more traffic than a well-known service, one of the inputs is wrong. That instinct, checking a result against the world rather than against the sum, is what people mean by engineering judgement in this context.

Every design decision costs something, and naming the cost unprompted is the strongest signal available in this format, because it is the thing that distinguishes having operated a system from having read about one. Interviewers are not testing whether you can name Redis; they are testing whether you know when it is the wrong answer.

The shape of a strong statement is decision, cost, and the condition that would change it. I would cache this with a sixty second expiry is a decision. Accepting up to a minute of staleness, because prices update hourly, is the cost. And if the prices became real-time I would drop the cache and read through is the condition. Three clauses, and the third is the one almost nobody says.

Volunteer the failure mode as well. What happens under partition, on a hot key, when the cache is cold after a restart, when the third party is down. Saying it yourself is worth far more than being asked, because being asked means the interviewer noticed the gap before you did, and that difference is exactly what the rubric is trying to detect.

Quantify wherever a number is available, even roughly. Adds a network hop, so maybe two milliseconds on the read path. Doubles our write volume. Saves an engineer a week of operating it. Numbers turn a preference into an argument, and an argument can be examined, which is the conversation you want to be having.

Say what you would not do and why, because a design defined only by inclusions looks like a list of technologies. I would not shard this yet, because the whole dataset fits in memory and sharding is the one decision that is genuinely hard to reverse. That single sentence demonstrates more judgement than three additional components.

Finally, be willing to change your mind when the interviewer pushes, and say what changed it. Defending a position past the point of evidence is a stronger negative signal than the original choice, and updating cleanly in front of someone is the behaviour they are hoping to see in a design review next quarter.