How to Prepare

Most candidates prepare for system design interviews by memorizing architectures for famous products. That gets you a design you can recite, not a design you can defend when the interviewer changes one requirement halfway through.

Build a small set of building blocks you actually understand

You don't need to know twenty technologies shallowly. You need five or six well enough to explain, unprompted, what breaks if you remove them:

• A relational database, and what a transaction actually buys you — e.g. Postgres won't let a payment get marked "captured" while the matching order row fails to insert, even if the app crashes mid-request.
• A cache like Redis, and the two ways it can lie to you: staleness (it still has the old value after the source of truth changed) and thundering herd (a hot key expires and every concurrent request misses at once).
• A message queue like Kafka or SQS, and what "at-least-once" delivery costs downstream — every consumer has to be idempotent, because the same message can arrive twice.
• A load balancer, and why sticky sessions are usually a smell: pinning a client to one instance defeats the point of having several, and turns a routine deploy into a wave of dropped sessions.
• An object store like S3, and why it isn't a filesystem — no atomic rename, no partial-write guarantees, and listing a "directory" is a paginated API call, not a syscall.

Practice explaining, not just drawing

A whiteboard full of correctly-labeled boxes with no narration reads as memorized. Practice saying the reasoning out loud as you draw: what you're solving for, what you're trading away, and what you'd revisit under different constraints (10x the traffic, a tenth of the budget, a hard latency ceiling).

Rehearse with numbers

Before the interview, get comfortable estimating orders of magnitude without a calculator: requests per second from daily active users, storage growth per year from an average row size, and read:write ratios for the kind of system you're designing. You will get these estimates wrong in the interview — that's fine. What matters is that your reasoning is visible and your numbers are in the right order of magnitude.

What to actually do the week before

1. Pick two or three systems you've used and sketch how you'd build them, alone, with no reference material. Time yourself.
2. Write down every trade-off you made and whether you could defend the opposite choice if pushed.
3. Say your design out loud to someone else, even if they don't work in tech. If they can follow it, an interviewer can too.