System Design Interview: Estimation and Interview Framework

The guest introduces himself: almost six years at the company, heading a unit responsible for online servicing and the mobile bank, and hoping to invite the host over once his own group starts on its next book. Then the getting-to-know questions: over his career he has written mostly in scripting languages, Python and Ruby, and would pick something more strictly typed if choosing again; he has no idols, but looks up to people who climb the upper grades of the individual-contributor track at large companies, and recently watched such an interview with a Google engineer. He came into IT through Phystech: he expected to become a scientist, realised science paid badly, and around the age of twenty started combining work with study.

The host slots in an unplanned segment on prioritisation frameworks: ICE, RICE and the value-versus-effort matrix. ICE has three scales — impact, confidence and ease — with the letters reordered, he notes, only to make the name readable. At work he runs task prioritisation this way: impact from 1 to 10, where one is ugly code you can live with and ten is a critical problem; confidence is how sure you are of the estimate; ease is how quickly the task can be solved, "like story points". RICE adds reach: a new argument on an endpoint may touch five per cent of users, while the value-versus-effort matrix shows what to do now but never says what not to do. The group tries estimating that endpoint change, and one of the participants objects: a candidate who starts estimating instead of asking why the thing is needed at all is a bad sign, and that is exactly chapter three.

Alexander's crib sheet for chapter two starts with powers of two: from binary it is convenient to step to the next power of ten, three zeros at a time, and attach the Greek prefix — kilobytes, megabytes and onwards. The heart of the chapter, though, is the table of what different operations cost; the one in the book is old, and he suggests looking for a fresher version published a year and a half or two years ago, with new rows added. What matters is not the numbers themselves but the orders: an L1 cache hit is roughly a nanosecond, while a round trip between continents is already fifty milliseconds. His advice is plain: study the table, think about what your code does, work out how many such operations the system has to perform per second, and compare that with what it actually does. His favourite story is about counters that need no persistence: he suggests putting them in Redis and hears back that millions of keys will never fit in memory.

He asks the audience how much a billion keys would take, and for scale reminds them that the planet holds seven billion people, so a billion users is not everybody's problem. The chat answers that it will fit in RAM — an experienced person, Alexander comments: with short keys and values it comes to something like twenty or thirty gigabytes, not every laptop, but server memory holds it with room to spare, and instead of designing sharding one cheap server is enough. He traces the habit of counting to around 2014 and a masterclass by one social network about how their memory was arranged, but warns against overdoing it: count only the parameters you need to size a solution — the load and the storage volume. Olga asks how to learn to count in one's head, since she has estimation experience but normally uses paper and a calculator. The advice from the group is to count on real cases and ask an experienced colleague to check, because the figures look fine until surprises appear.

Alexander recalls a site already ten years old: a contractor moved it onto new rails, everything fitted in memory at first, and three or four months after handover the system began to hang — the approach the contractor had chosen did not suit, and caching had to be reworked, fetching elements in batches with multi-get to cut the number of requests. The host adds his own story: a table taking three million rows a day looked trivial, grew to a terabyte on the cluster within six months, the system started to choke, and a cleanup queue saved it. Hence the main criterion: find the points where one machine stops being enough. More than ten thousand write operations per second is a warning that plain PostgreSQL may not hold; hundreds of thousands of requests per second into particular endpoints, or several terabytes of data, likewise. And traffic should be counted per second: monthly figures interest only analytics, and a candidate who divides daily traffic by the number of seconds forgets the peaks — night, day, and the moment everyone piles in at a match kick-off.

What to expect from a candidate on peak load depends on their level: a strong one asks about the load profile and the maximum, and proposes elastic infrastructure or deferring part of the load — though in an interview you usually agree on the simpler version and mark the extra complexity with an asterisk, so as not to bury the person straight away. Good candidate questions get collected round the circle: Pavel describes a candidate who picked storage by what the team already knows: not a great answer on its own, he grants — you cannot always choose by what the team knows — but operating a familiar tool often matters more than theoretical fit; Alexander recalls one who opened with the constraints — budget, team, the building blocks on offer. The opposite signal is the salesman of a single answer, along the lines of "nothing can be built without Kafka, I have just done the course". Alexander closes by walking through the book's four steps: understand the task and do not be shy with questions, show a high-level design and check it with the interviewer, dive into the components that matter, and wrap up with operations and scaling. He dislikes five alternative designs — that shifts responsibility; better to pick one and explain why. His favourite follow-up question is a blackout: the power is gone, how do you bring the system back? They finish with the traditional photo with the book.