Member-only story
Featured
100 System Design Terms You Should Be Able to Explain in an Interview
Each one defined in a sentence, explained by how it actually works, and paired with the trade off an interviewer expects you to name.
Most candidates who struggle in a system design interview do not lack understanding. They lack precision.
They say the database “might get slow,” that the service “should handle failures,” that the data “syncs eventually.”
Each of those sentences points at a real idea, and each leaves the interviewer unsure whether the candidate actually knows it.
Compare two answers to the same prompt.
The first: “We could put a cache in front of the database so things are faster.”
The second: “Reads outnumber writes about fifty to one, so I would add a cache aside layer with a short TTL, accept a few seconds of staleness, and watch the hit ratio.”
The second candidate did not know more concepts. They used the right words, and the right words carry the trade offs inside them.
Interviewers are listening for exactly that. A precise term tells them you have met the problem before. A vague phrase tells them you have read about it.
