Requirements

The first ten minutes write the rubric the other fifty are graded against. Say the prompt back, name what the system does, ask how well it has to do it, and put the answers where you can point at them at the end.

What is the difference between functional and non-functional requirements?

Functional requirements are what the system does: who uses it and the three to five operations they perform, like put a key and get a key. Non-functional requirements are how well it has to do them: how many requests a second, how fast, how much downtime, how stale a read may be, whether data may be lost. The first list decides the boxes on the diagram. The second decides nearly every choice after that, which is why it is the list to spend most of the ten minutes on.

Which questions should I ask first in a system design interview?

Five, in this order. Who uses it and what do they do most. How many: users, requests a second at the peak, data kept. What share of requests are reads. How fresh a read must be. What may never happen: data lost, or the service down. Each answer narrows the next, and together they decide the store, the number of copies and whether there is a cache. Latency, region, cost and compliance come after, one quick question each.

What do I say when the interviewer tells me to assume any scale I like?

Pick a number that is round, plausible for the product, and large enough that one machine is not enough, then say it and ask for the nod. On a key-value store I would say forty thousand requests a second at the peak, three in four reads, and two billion keys of about a kilobyte. A number you say can be confirmed or corrected. A number you only think about earns nothing, because the reasoning is never heard.

How long should the requirements phase take?

About ten minutes in a sixty-minute round, and about five in a forty-five minute one, with the envelope arithmetic starting inside that window. The exit criterion is concrete: the prompt restated and nodded at, three to five operations, two or three things out of scope, and six to eight non-functional answers with numbers. When those are on the board, move, even if you could think of more questions.

Does one unasked question really change the design?

It changes the numbers the design is sized on. On a key-value store at forty thousand requests a second, guessing nineteen reads in twenty instead of asking and hearing three in four plans twenty-eight nodes instead of thirty. The cluster built on the guess tops out at about 37.3 thousand requests a second, below the peak, and it was planned for a fifth of the real writes.