Let's Make System Design Work: What It Actually Is

Most engineers meet system design for the first time in an interview, which is a shame — because it makes the whole thing look like a test you pass by memorising architectures.

It isn't. The idea is simpler than that.

System design is drawing how a system is.

That's the whole premise. Before the code exists, you describe the shape of the thing: what the parts are, where the boundaries sit, and what moves between them.

What you're actually drawing#

Five things come up, and it helps to know which is which.

Architecture — the shape of the whole system. The major pieces and their relationships. This is the altitude where the expensive decisions live.

Components — the individual pieces. A service, a cache, a queue, a client app.

Modules — how a component is divided internally, and where each boundary sits.

Interfaces — the contracts between parts. What one piece promises another, independent of how it delivers on it.

Flows — what moves through the system, in what order. A request arriving, a message being published, data working its way to a screen.

It's a translation, not an invention#

Here's the framing that makes system design click:

It's a way to translate requirements into a plan.

Not a diagram for its own sake. Not a demonstration that you've read about Kafka. A plan, for a problem somebody actually stated.

Which means the input matters more than the output. Without requirements, you're not designing — you're guessing at a shape and hoping it matches the one in the interviewer's head.

This is why every good system design conversation starts with questions, not boxes:

• How many users? Now, and in a year?
• Read-heavy or write-heavy?
• Does this need to be real-time, or is a minute of delay fine?
• What must never break, and what can degrade?
• Are we global, or one region?

None of those are stalling tactics. Each one eliminates entire branches of the design. If the answer is "ten thousand users, one region, eventual consistency is fine," then anyone who starts sharding a database has stopped listening.

The real content is trade-offs#

Every box you draw costs something. The design isn't the boxes — it's why you chose these and not the others.

Four axes come up constantly:

Scalability — does this shape hold when traffic multiplies? And is it worth paying for that headroom today?

Cost — what does running this actually cost? A design that works and bankrupts the team is not a working design.

Security — what did you just expose? Where does data live, who can reach it, what crosses a trust boundary?

Complexity — who maintains this? Every component is something that can fail at 3am, and somebody has to understand it well enough to fix it.

The seniority signal isn't picking the "right" option. It's naming the cost of the option you picked.

"We'll add a cache" is a junior answer. "We'll add a cache — it cuts read latency and database load, but now we own an invalidation problem, and stale reads have to be acceptable for this data. For a product catalogue that's fine. For account balances it isn't." That's the same decision, with the reasoning attached.

High level or low level#

You can design at either altitude, and the high level is normally taken more seriously. It's where decisions are expensive to reverse.

High level: services, data stores, queues, the client, the boundaries between them.

Low level: a specific schema, a class hierarchy, the exact shape of a payload.

Practical advice — start high and stay there until you're invited down. Diving into table columns in minute three means you'll never get to the architecture, and the architecture is what's being marked. When the interviewer asks "how would you model that?", that's the invitation.

What the interviewer is actually assessing#

This is the part most people get wrong, so it's worth being blunt. The goal is not to see whether you can reproduce Twitter's architecture from memory. The goals are:

How you think. Can you build a solution from the requirements, and stay flexible when they change? Interviewers routinely add a constraint halfway through — not to trip you, but to see whether your design bends or shatters.

Your repertoire. What have you seen? Not to recite, but to reach for. Someone who's operated a message queue talks about them differently from someone who's only read about them.

Whether you know which solution to use. Knowing ten options is worth little without judgement about which one fits this problem. Reaching for microservices on a two-person team is a red flag, not a strength.

Communication. If your diagram and your explanation are comprehensible, you have good communication. That's the actual test. A design nobody can follow has failed, however correct it is.

Collaboration. Talk. Chat. Ask. Don't just build the system in silence. This is a working session, and they're imagining you in a real design review.

The specific skills the company needs. Sometimes there's a concrete thing they're probing for, because it's what the role does every day. Mobile-heavy team? Expect offline sync and conflict resolution. Fintech? Expect consistency and audit trails.

Read that list again and notice how much of it isn't the diagram. Roughly half the scorecard is whether someone would want you in the room.

The one mistake to avoid#

Designing in silence.

A candidate who fills the board with a beautiful diagram while saying nothing scores worse than one who draws something rougher while narrating the trade-off they're weighing. The interviewer cannot mark what they cannot see, and thinking is invisible unless you say it.

So say it. "I'm choosing a queue here because the write path can be async — the trade-off is that the user won't see it immediately." "I'm assuming reads dominate; tell me if that's wrong." "I could split this into two services, but with this team size I'd keep it as one module and revisit."

That narration is the exercise.

Wrapping up#

System design is drawing how a system is, in order to translate requirements into a plan — and then defending that plan in terms of scalability, cost, security and complexity.

Stay at the high level until invited lower. Ask before you draw. Name the cost of every choice. And talk the whole way through.

In the next post we'll take a real prompt — "design the backend for a mobile feed" — and work it end to end, requirements first, with the questions I'd ask at each step.

Until then, let's make this work.