System design interviews vs shipping systems

Interview system design rewards breadth: boxes, arrows, and a confident voice. Production rewards boring correctness under partial failure — usually at an hour nobody scheduled a meeting for.

Both skills overlap. They are not the same sport.

What transfers

These habits from the whiteboard actually survive contact with prod:

• Naming the bottleneck before drawing boxes
• Choosing consistency vs availability per use case, not as a slogan
• Designing for operability: metrics, ownership, rollback

If your diagram has twelve microservices but no owner for the payment path, it is a poster, not a plan.

What does not

Some interview habits age badly once traffic and invoices show up:

• Perfect CAP slogans with no traffic shape
• Microservices as a default personality
• Ignoring cost until finance finds the invoice

“Eventually consistent” is fine until the customer refreshes twice and sees two different balances. The interview room nods. Support hears about it.

A better practice loop

Take one production incident. Redraw the design that would have made that failure mode obvious earlier — not prettier, earlier.

Where would a trace have shown the retry storm? Which metric would have turned red before the database did?

That exercise teaches more than another “design Twitter” session. It also produces ADR material someone might actually read.

Takeaway

Use interview diagrams as communication tools — then validate them against load, failure, and the people who will run the system at 2 a.m.

The whiteboard is the draft. Production is the edit.