How to explain system design in English

Use a spoken order, not a perfect diagram: clarify requirements, estimate load, propose APIs, sketch storage, then defend two trade-offs. Short sentences beat silence. Practise saying each step out loud before you draw.

Start with a seven-step framework, then one storage case (Pastebin), one feed (Instagram or Twitter), and one concurrency or geo case. Narrate each case for 20–30 minutes. The English of trade-offs is what panels score.

Almost never by themselves. Panels fail candidates who go quiet, cannot name a trade-off, or cannot follow a follow-up. A clear accent with a spoken structure beats perfect grammar and a silent whiteboard.

Use a three-part line: option A, option B, and why you pick one for this load or team. Example: “We can fan-out on write or on read. I would fan-out on write here because read latency matters more than write cost.” Rehearse that skeleton until it is automatic.

Aim for a 35–45 minute shape: two to three minutes clarifying, five on estimates and APIs, then a high-level design with two deep dives. Leave five minutes for bottlenecks. If English slows you down, shorten each segment with rehearsed phrases rather than skipping structure.

Describe it in plain English and keep going: “a fast copy of hot data,” “split the data across machines,” “every replica shows the same value.” Interviewers score the idea. Stopping to search for the textbook term is what looks junior.

You need both, but speech leads. Say the component, then draw it. UK/US panels cannot score a diagram they cannot hear you justify. Practise talking while you box and arrow, not after you finish the picture.

State the assumption, do the maths slowly, and say the unit. “Assume 10 million daily actives, 10 reads each, about 1,200 reads per second.” Round numbers are fine. Narrate the arithmetic so the interviewer can correct you early.