How to Approach a System Design Problem

Ask functional requirements (what must the system do?) and non-functional ones (how many users, how much data, read/write ratio, consistency needs, latency targets) before designing anything. Explicitly state what you're choosing NOT to build.

• "Should I focus on the read path or the write path first, given what you're most interested in?"
• Write the agreed requirements somewhere visible (a whiteboard corner, a shared doc) so you can refer back to them.

Turn the requirements into rough numbers: requests/sec, storage growth per day, read/write ratio. These numbers should directly justify later choices (a cache, a CDN, sharding) rather than existing as a disconnected math exercise.

• Round aggressively — the goal is order-of-magnitude, not precision.
• State the number and immediately connect it to a decision: "4,000 reads/sec and a 100:1 read/write ratio means I want caching in front of the database."

Write the handful of API endpoints (or RPCs) the system needs, then sketch the core entities and their relationships. This forces you to nail down the actual contract before drawing boxes and arrows.

• Keep the API to the essential operations — you can always add more if time allows.
• State your data-store choice here and justify it with one sentence, referencing SQL vs NoSQL trade-offs.

Sketch the main components (load balancer, application servers, cache, database, queue) and how a request flows through them for your primary use case. Narrate the flow left to right as you draw it.

• Start simple (a monolith with a database) and layer in caching/queues/sharding as you justify the need for each — don't start with every primitive at once.
• Check in: "Does this architecture make sense so far, or would you like me to adjust anything before I go deeper?"

The interviewer will usually steer you toward one component to go deeper on (the caching strategy, the sharding key, how consistency is preserved). Treat this as the main event — it's what actually differentiates candidates, not the initial diagram.

• If the interviewer doesn't steer you, ask: "which part would you like me to go deeper on — I'd suggest the caching layer or the data partitioning?"
• Bring in trade-offs explicitly here: "I could use a stronger consistency model, but it would cost us availability during a partition — here's why I'm choosing eventual consistency for this specific field."

If time allows, proactively name the biggest remaining bottleneck or single point of failure in your design and how you'd address it next. This shows self-awareness the interviewer doesn't have to extract from you.

• "If I had more time, the next thing I'd address is X, because Y."
• It's fine to end with open questions rather than a perfectly polished design — a thoughtful trade-off list beats a rushed extra diagram.

• Have a rough time budget per step before you start (requirements → estimates → API/data model → architecture → deep dive → wrap-up).
• Practice connecting every estimate to a concrete design decision, out loud.
• Know 2-3 go-to deep-dive topics cold: caching strategy, sharding key choice, consistency trade-offs.
• Practice explicitly inviting the interviewer to steer you ("which part should I go deeper on?") instead of guessing.