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? Naming that explicitly — "this can be eventually consistent, this cannot" — is usually the single highest-leverage sentence in the interview.
A multiplayer game position update, a sensor reading, and a checkout event all have wildly different tolerance for staleness and loss. A few more that hold up across domains:
- Where does back-pressure go when the downstream is slow? Buffer, drop, or block — say which, and why, for your case.
- What's the unit of retry? If a step fails, what exactly gets retried, and is that operation idempotent?
- What's the blast radius of a bad deploy, and how fast can you detect it?
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.