The System Design Interview, From a Generalist's Toolbox

System design interviews reward pattern recognition more than domain trivia. Having worked across game networking, embedded firmware, and web backends, the thing that transfers isn't specific technology — it's a short list of questions I ask regardless of what's on the whiteboard.

The questions that transfer everywhere

What's the actual consistency requirement? A multiplayer game position update, a sensor reading, and a checkout event all have wildly different tolerance for staleness and loss. Naming that explicitly — "this can be eventually consistent, this cannot" — is usually the single highest-leverage sentence in the interview.

Where does back-pressure go when the downstream is slow? Every system I've built has had some component that occasionally can't keep up: a renderer at 11ms instead of 16, a Bluetooth link that drops, a database under load. The answer is always some combination of buffering, dropping, or blocking — say which, and why, for your specific case.

What's the unit of retry? This is the embedded-systems habit that's most underused in web system design interviews. If a step fails, what exactly gets retried, and is that operation idempotent? Candidates who can answer this crisply tend to stand out.

Translating game-networking intuition to web systems

Client-side prediction and server reconciliation — from multiplayer games — maps surprisingly well onto optimistic UI updates with server-authoritative rollback in web apps. If you've built either, say so; interviewers respond well to a concrete prior example over an abstract textbook answer.

What not to do

Don't reach for a specific vendor product as your whole answer ("just use Kafka"). Say what property you need — ordered, durable, replayable — then name a tool as an example of something with that property. That signals you understand the trade-off, not just the brand name.