Practise Explaining System Design Out Loud

You can read about caching, rate limiting and database indexes for weeks and still freeze when someone says, "Walk me through how you'd design it." The knowledge is there. What's missing is practice at turning it into clear spoken sentences, in order, while someone listens.

A system design interview is mostly talking. You narrate your assumptions, explain each box you add, and justify the trade-offs as you go. That's a skill of its own, and like any speaking skill it improves with repetitions: short, regular, out loud.

This guide gives you a structure for any system design or database explanation, a worked example, and a daily drill that takes about 15 minutes of talking and reviewing.

Why reading isn't enough

When you read an article on consistent hashing, the author has already done the hard part. They chose the order, picked the example and decided what to leave out. You follow along and it all makes sense.

When you explain it yourself, you have to make those choices live:

• What comes first? Start with a hash ring diagram and you lose the listener. Start with the problem it solves and they follow.
• How deep? Too shallow sounds like buzzwords. Too deep and you run out of time before the trade-offs.
• What's the "why"? Interviewers rarely stop at "use a cache". They ask why there, why that eviction policy, and what happens when it's stale.

You only find your gaps when you try to say the thing out loud. A sentence that starts confidently and trails off into "and then it basically handles it" marks exactly what to study next. That's the same idea behind the Feynman technique, applied to technical topics.

A five-part structure for any design explanation

Whether the topic is a whole system or one concept, this order keeps a spoken explanation easy to follow.

1. The problem, in one or two sentences. What goes wrong without this? "If one client sends thousands of requests a second, everyone else's requests slow down or fail."
2. The core idea. The simplest version of the solution, before any detail. "Give each client a budget of requests per time period, and reject requests over it."
3. How it works. The mechanism, with one concrete example. This is where the main approaches and their differences go.
4. Trade-offs. What each choice costs, and when you'd pick another one. Interviewers listen hardest here.
5. Where it breaks. Failure modes, edge cases and what you'd do about them. Ending here shows you've thought past the happy path.

It works at any length. In a two-minute answer each part gets a sentence or two. In a ten-minute talk, part 3 grows and part 4 gets examples.

If the topic is a full system rather than one concept, add a step before the core idea: the requirements and scale you're assuming. The difference between the big picture and the detailed design is covered in HLD vs LLD.

A worked example: rate limiting

Here's how a three-to-five-minute talk on "How would you cap how many requests each client can make, and what happens when a client goes over?" could go, using the structure above.

The problem. One client, maybe a buggy script, can send so many requests that the service slows down for everyone. We want each client to get a fair share and to protect the backend.

The core idea. Track how many requests each client makes in a period. Once they go over the limit, reject further requests until the period resets or capacity frees up.

How it works. There are a few common algorithms:

• A fixed window counts requests per clock window, say per minute. It's simple, but a client can send a full window's worth just before the boundary and another just after, so the real burst can reach twice the limit.
• A sliding window looks at the last 60 seconds from now rather than the clock minute, which smooths out that boundary burst.
• A token bucket holds up to a set number of tokens and refills at a steady rate. Each request spends one, so short bursts are allowed up to the bucket's size, while the average rate stays capped.
• A leaky bucket queues requests and lets them out at a constant rate, which smooths traffic but adds delay.

Trade-offs. First, what do you key the limit on? A user ID or API key is fair per customer. An IP address works for anonymous traffic, but many users behind one office or mobile network can share an address. Second, with several servers the counts must be shared, usually in a central store such as Redis. Then a read-then-write race can let extra requests through, so the increment needs to be atomic.

Where it breaks. If the central store is down, do you allow everything (fail open) or reject everything (fail closed)? It depends on what you're protecting. And the client needs to know what happened: respond with HTTP 429 Too Many Requests, usually with a Retry-After header saying when to try again.

That's four or five minutes of spoken content, and every part of it can prompt a follow-up question. Notice what the talk doesn't do: it doesn't list every algorithm ever invented, and it doesn't start with Redis.

The same structure for a database topic

Database questions work the same way. Take "How does an index make a lookup fast, and why not put an index on every column?"

• Problem: without an index, finding rows that match a condition means scanning the whole table.
• Core idea: keep a separate, sorted structure that points to the rows, so lookups jump straight to the matches.
• How it works: most indexes are B-trees. A lookup reads a few pages from the top of the tree down, and a range query reads along the leaves.
• Trade-offs: every index slows down inserts and updates and takes space. An index on a yes/no column rarely helps, unless you're searching for a rare value.
• Where it breaks: a query that wraps the column in a function or casts its type may not use the index, unless the index is on that same expression.

Practising explanations like this out loud is also good preparation for the follow-ups. Each bullet is something an interviewer might ask about.

The daily drill

You don't need a mock interviewer to practise. You need a topic, a timer and a way to hear what you said.

1. Pick one topic. One concept, not a whole system: caching, CAP, consistent hashing, sharding, indexes, transactions. Decide quickly.
2. Prepare for 15 to 30 minutes. Read with the five parts in mind. Write keywords for each part, not sentences. If you write a script, you'll practise reading, not explaining.
3. Talk for three to five minutes. Out loud, standing up if it helps. Don't stop to restart when a sentence goes wrong. Recover and keep going, as you would in an interview.
4. Review for five minutes. Listen back, or better, read a transcript. Check three things. Did you cover the points that matter? Where did you get vague? Did you say any trade-off out loud, or only describe the happy path?
5. Write one fix for next time. "Say the problem before the solution." "Give a number when I say 'a lot'." One fix per day is enough.

Doing this most days builds something reading can't: the habit of giving a structured spoken answer on demand. The general version of this routine, for any topic, is in the 10-minute daily speaking method.

Doing it with Daily Talk

Daily Talk on EditMyStuff is built for this kind of practice, and it has System Design and Database categories. Technical categories are opt-in: choose one before you spin, and your topics stay in it.

Each System Design or Database topic comes with a prompt, like the rate-limiting question above, and a short list of points to cover: the three or four things a good answer includes. You get up to an hour of research with Wikipedia, Google and YouTube links and a notes box, then record a talk of 1 to 10 minutes. It's turned into a transcript in your browser, with its length, word count and speaking pace, and the audio is never uploaded. Transcription is English for now.

If you sign in, you get one free AI attempt a day for feedback on that day's talk. It scores structure, clarity, depth and examples, and notes what worked and what to try next time. For System Design and Database talks it also points out statements that look technically wrong, each with a correction, and which of the points to cover you left out. Treat that as a second opinion: AI feedback can be wrong too, so check anything that surprises you against a reliable source.

Frequently asked questions

How long should a practice talk be?

Three to five minutes is a good default for one concept. That's roughly how long you'd spend on one component in an interview before the next question. Try a ten-minute talk now and then, to practise going deeper without losing the structure.

Should I practise with a whiteboard or diagram?

Both help, but speaking is the part people skip. In a real interview you'll describe what you're drawing as you draw it, so practise saying it in words. If you can explain the request path clearly without a diagram, adding one only makes it easier.

What if I don't know a topic well enough to talk about it?

That's useful too. Prepare for 15 minutes and give a two-minute talk anyway. Where you get stuck shows exactly what to read next, and explaining from limited knowledge is a skill interviews test.

Is the AI feedback in Daily Talk always right?

No. It's a quick second opinion on your transcript, not a verdict. Its technical corrections and "claims worth checking" are prompts to look things up. Confirm them against documentation or a good textbook before you change what you say.

Can I practise in a language other than English?

Not yet. Daily Talk transcribes English for now, so a talk in another language won't produce a usable transcript.