Free System Design Interview Questions in English

The six-beat spoken outline

1. 1.Requirements

   Who the user is, and what must work on day one. Clarify identity, write vs read, and one thing you are not building yet.

2. 2.Scale

   One rough number you can say out loud. QPS, storage, or “millions of keys.” The number can be rough. The sentence cannot be missing.

3. 3.API

   Name the two or three calls. “I would expose allow(userId) and a 429 when they are over the limit.”

4. 4.Data

   Where the state lives. Cache, database, or log. Say why that store, not a tool dump.

5. 5.Bottleneck

   What breaks first when traffic grows. Hot key, single leader, clock skew. Invite a follow-up.

6. 6.Trade-off

   What you gain and what you give up. Accuracy vs speed, consistency vs availability. One pair is enough.

Practise a prompt

Pick a classic prompt, talk for 60–90 seconds, and get a scorecard on that outline. You do not need to draw.

• Spoken outline

  Rate limiter

  A rate limiter is a “who, how many, what happens at the limit” story. Clarify identity, pick token bucket or a window, place it before expensive work, then name fairness.

• Spoken outline

  URL shortener

  A URL shortener is two paths: write a long URL, redirect a short code. Name how you mint the ID, where you store the map, and what you do on a collision.

• Spoken outline

  Unique ID generator

  Unique IDs are a “unique, roughly ordered, and cheap to mint” story. Name a Snowflake-style split, then clock skew — that is the follow-up they will ask.

How to explain your system design diagram in English

Use the same six beats whether you drew the boxes or someone else did: requirements, one scale number, API, where data lives, the first bottleneck, then one trade-off. While you speak, walk a request path — do not only read labels left to right.

Walking the diagram

• “On the left is the client. A request goes through the load balancer to the API.”
• “From the API we check the cache before we hit the database.”
• “If the cache misses, the request falls back to the primary store.”
• “Writes go to the queue so the API can return quickly.”

Common mistakes

• Pointing without naming (“this thing”, “here”) — the interviewer cannot see your cursor.
• Reading boxes left to right with no story — no request path, no “what happens next”.
• Never giving a number — even a rough QPS or “millions of keys” anchors the design.
• Skipping the bottleneck and trade-off — the panel will ask anyway.