How to explain a system design, step by step

You’ve probably seen this happen. Someone walks up to the whiteboard (or shares their screen) and says, “Okay, let me explain how it works.” Then they draw a load balancer. Then three services. Then a queue, a cache, two databases, a worker, a webhook, and an arrow looping back from somewhere to somewhere else.

Ninety seconds in, the whole thing is on the board, and half the room is quietly nodding along while trying to work out where to even start looking.

The problem usually isn’t the design. The problem is that the person explained it all at once, and people don’t take in systems all at once. They take them in the way the system itself runs: one thing happens, then the next thing, then the next. Explain it the same way, and it works everywhere: interviews, design reviews, onboarding docs, and that “wait, how does billing actually work?” Slack thread nobody wants to answer.

The one idea: a system design is a story

Here’s the reframe that makes everything else easier:

The boxes are the cast. The arrows are the plot.

Nobody explains a movie by listing every character first and then describing every scene in parallel. You follow someone through events in order. A good system explanation works the same way: pick one request and follow it from the moment it starts to the moment it’s done.

Quick check before you read on: think of a system you know well. Can you name the first thing that happens when a user uses it? Not the architecture, just the first hop. If you can, you already have the opening line of a good explanation.

The method, in six steps

The short version:

1. Start with one user doing one thing.
2. Introduce only the components that request touches.
3. Walk it one hop at a time: who talks to whom, what they send, and why.
4. Slow down at the hops where something can fail, be slow, or change hands.
5. Only then zoom out to failures, async work and scale.
6. Hand over the controls: “which step do you want to dig into?”

Now each one in a bit more detail.

1. Start with one user doing one thing
Say it in one sentence, out loud, before you draw anything: “A customer clicks Pay on the checkout page.” That sentence is your scope. Anything the request doesn’t touch stays off the board for now, however proud you are of it.

2. Introduce the cast, but only the ones in this scene
List the components this one request will pass through, in the order it meets them. Customer, web app, API, orders database, payment service, payment provider. Six names to start. The queue and the email worker can wait until the async part, and nobody needs to hear about all fifteen. Your listener now has somewhere to hang every detail that follows.

3. Walk it one hop at a time
Every step should answer three things: who talks to whom, what they send, and why. “The API asks the payment service to create a charge, because the API shouldn’t know anything about card details.” One arrow, one sentence, then move on. If you catch yourself saying “and meanwhile…”, stop. That’s a second story, and it gets its own turn.

4. Slow down at the hops that matter
Most hops are boring, and that’s fine. Say them quickly. The ones worth pausing on are where something can fail, where something is slow, or where state changes hands. “This is the step where the provider can time out after charging the card. Here’s what we do about that.” That pause is where your judgment shows. In an interview, it’s where the actual signal is.

5. Only then, zoom out
Once the happy path is clear, add the next layer: the failure path, the async work that happens afterwards, what changes at 100x the traffic. Your listener can follow it now because each new piece attaches to a story they already understand, instead of floating free in a diagram.

6. Hand over the controls
Finish with “which step do you want to dig into?” rather than “any questions?” A step number gives people a concrete handle. “Can we go back to step 4?” is a far easier question to ask than “can you explain the… thing… near the queue?”

Let’s try it: what happens when a customer clicks Pay

Here’s the checkout example written as a flow, one line per step, in the order things happen:

Customer -> Web App: clicks Pay
Web App -> API: POST /checkout with cart + idempotency key
API -> Orders DB: create order (status: pending)
API -> Payment Service: charge $1,499 for order #812
Payment Service -> Payment Provider: create payment intent
Payment Provider -> Payment Service: payment succeeded
Payment Service -> Orders DB: mark order #812 paid
Payment Service -> Queue: publish order.paid
Payment Service -> API: charge confirmed
API -> Web App: 200 OK, redirect to confirmation
Queue -> Email Worker: send receipt

Read it top to bottom and notice what it does for you. You never see all eleven arrows at once. You see step 3 knowing exactly how you got there. And the interesting questions come up on their own:

• Why does the order exist before the payment? (Step 3: so a crash mid-payment leaves a trace instead of a charged card with nothing attached.)
• What’s the idempotency key for? (Step 2: so a double-click or a retry doesn’t charge someone twice.)
• Why is the receipt going through a queue? (Steps 8 and 11: the customer already has their confirmation at step 10, so a slow email server can’t make checkout slow.)

Here’s that same flow as a live diagram. Press Next and step through it yourself:

Try something while you’re in there: stop at step 5 and ask yourself what happens if the provider never replies. That’s exactly the kind of question a static box-and-arrow picture makes hard to ask, because there’s no “step 5” to point at.

The mistakes that lose the room

A few patterns that come up again and again, including from very senior engineers:

• Drawing the whole architecture first. It feels thorough, but it front-loads the part your listener can’t make sense of yet. Earn the big picture by walking through a request first.
• Unlabelled arrows. An arrow from API to Database says something happens. “Create order, status pending” says what happens. The label is the explanation, and the arrow is only a pointer to it.
• Mixing sync and async without saying so. “The worker sends the email” hides the most important fact, which is that the user isn’t waiting for it. Say it out loud: “This part happens after we’ve already responded.”
• Double-headed arrows. A request and its response are two separate events, and often the interesting part lives in the gap between them. Draw two arrows.
• Skipping the why. “Then it goes to Redis” is a fact. “Then it checks Redis, because this lookup happens on every page load” is a design decision. Only the second one tells anyone something they couldn’t have guessed.

Explaining it in a system design interview vs. a design doc

In a system design interview, the method stays the same but the pacing changes. Say the one-sentence scope and check it with the interviewer (“should I focus on the write path?”). Walk the happy path in two or three minutes, then spend most of your time on the hops that matter. Interviewers aren’t scoring how many boxes you drew. They’re watching where you choose to slow down.

In a design doc or onboarding page, your reader can’t interrupt you, so the steps have to carry the explanation on their own. Number them. Keep one idea per step. Put the “why” right next to each hop rather than in a separate rationale section three screens below. And pick a format where the diagram can’t quietly drift out of date. (We’ve written about why most documentation diagrams are already wrong.)

Try it on your own system

Pick the one flow your team explains most often: login, checkout, a deploy, a support escalation (it doesn’t have to be software). Write it as one line per step, Who -> Whom: what happens, in the order it happens. You’ll probably find a step you can’t quite explain yet. Honestly, that’s the most useful thing this exercise can turn up. Then paste those lines into Flostep (no account needed), and your team gets a diagram they can step through at their own pace.