"The service generates a short code and stores it" sounds finished until someone in the review asks what happens when two instances generate the same code at the same moment. The diagram did not change between those two sentences. What changed is that the explanation had to cover a case the drawing never showed.
Most of the time in a design review goes to that second sentence: why the box is there, what the arrow promises, and what happens when the request does not go as drawn. You can get better at it the way you get better at anything else, by attempting it, finding out what you missed, and trying again.
A review asks the same few questions
The questions in a design review are predictable, even when the system is not. What does it need to do? Which qualities matter, such as latency, durability, or how stale a read may be? What are the main things it stores, and how do clients ask for them? What happens to one real request, end to end? What breaks first when traffic, data, or a dependency misbehaves?
A system-design interview asks the same questions in a fixed order: functional requirements, non-functional requirements, core entities, the API, a high-level design, and deep dives. Whether you are presenting to colleagues or to an interviewer, the order is a useful checklist. If you cannot answer one of these questions about your own design, the drawing will not answer it for you.
Walk one request: a URL shortener
Take a fictional link service for a marketing platform. Customers paste a long link and get a short one. Anyone who opens it reaches the original page. Some customers choose their own code. Assume links are opened about 100 times as often as they are created, and that a briefly stale redirect is acceptable.
A first drawing has a client, a URL service, and a links database. Now explain the creation path aloud and listen for the gap.
Unique codes. "The service generates a random code" leaves the collision question open. Say where uniqueness is enforced. One answer: the database holds a unique constraint on the code, the service retries with a new code when an insert fails, and a customer-chosen code that is already taken returns an error instead of a retry. Another: each service instance reserves a range of IDs and encodes them, so instances never hand out the same one. Both work. Each gives something up: retries add a write on conflict, and reserved ranges leave gaps when an instance stops. The point is to name the mechanism and its cost, not to pick the one correct answer.
Popular redirects. "We cache redirects" needs its second sentence too. At 100 opens per create, most traffic is reads of rows that rarely change, so a cache in front of the database takes most of that load. Say what happens on a miss, which store holds the authoritative copy, and how long a cached redirect may outlive a change. Here the stated requirement allows a briefly stale redirect, which is what makes a simple time-based expiry acceptable. If owners could disable a link and expect it to stop at once, the cache policy would have to change.
Neither answer needed a new box. Both needed a sentence that tied the box to a requirement and said what it costs.
What makes practice useful
Reading a strong design helps you recognise one. It does not make you produce the second sentence under questioning. For that, practice needs four things:
- A question with a stated scope, so you know which requirements you are designing for.
- Saying the design, not only drawing it. Gaps that hide in a diagram show up when you have to explain an arrow aloud.
- A check against criteria after each stage, so you find out that you skipped collisions while the design is still in front of you.
- A chance to revise that stage and check it again before moving on.
You can do this with a colleague: one person explains, the other asks only "what happens when…" questions and keeps a list of what was not covered. Swap after each stage.
Practise it on your own with Grind
Grind is Lycana's system-design interview practice, and it is built around that loop. You pick a question and work through it one step at a time, from requirements to deep dives. You answer by voice, typed commands, or direct editing, with the same command bar as Lycana's diagram app. On the design steps, Lycana builds an editable diagram from what you say.
When a step is ready, you check it. The feedback says what you covered against the question's criteria. What you missed stays hidden until you ask to see it, so you can look for it yourself first. Then you revise the step and check it again.
Grind uses your Lycana account and plan. A Free account gets one junior or mid-level question; further practice requires Lycana Pro. See current plans. For why Grind has you talk through a design instead of drawing it, read Why Grind has you talk, not draw.
The URL shortener above is one of Grind's questions. Before your next review, try it and see how many of its second sentences you say without being asked.
