I've taught system design to hundreds of engineers. Here's where I tell them all to start.

Somewhere around the hundredth engineer I coached, I noticed something. Nobody was struggling with system design because it was too hard. They were struggling because they started in the wrong place.

The pattern was always the same. A smart engineer with two or three years of experience decides it's time to learn system design. They search YouTube, land on "Design Instagram in 45 minutes," and watch someone draw fifteen boxes connected by arrows. They understand maybe four of the boxes. They finish the video feeling like they learned something, try to design anything on their own, and produce a server, a database, and silence.

Then they conclude system design is a genius-only club, and they either give up or start memorizing diagrams.

If that's you, nothing is wrong with you. You just entered the building through the roof.

The lie that keeps beginners stuck

Here's what I wish someone had told me when I was coming up through Microsoft and Facebook: system design is not as big as it looks.

It looks infinite because content about it has no agreed-upon sequence. Every blog post assumes you already know whatever the last blog post covered. Every video introduces five terms it never defines. There's no "chapter one" anywhere on the front page of Google.

But strip the noise away and the field that matters for interviews and for real engineering work reduces to roughly 12 recurring patterns, combined in different ways. Netflix is not magic. Uber is not magic. They're the same dozen ideas arranged for different constraints.

You cannot see that from the roof. You can only see it from the foundation.

The 5 concepts I make everyone learn first

When someone asks me where to start, I give them the same assignment every time: learn these five things, and don't touch a case study until you can explain each one to a non-engineer.

1. The client-server model. A client asks, a server answers. Every system you will ever design begins with "the client sends a request to our API server." If this sentence isn't boring and obvious to you yet, everything downstream will feel like fog.

2. Databases. Where data lives when the power goes out. You need exactly one distinction at this stage: SQL databases are structured and relational, NoSQL databases are flexible and easier to scale horizontally. That's it. Do not fall down the "PostgreSQL vs Cassandra vs DynamoDB" rabbit hole in week one.

3. APIs. The contracts that let pieces of software talk to each other without knowing each other's internals. In a design discussion, APIs are the seams of your architecture: where you cut, and where things can change independently.

4. Load balancing. One server can't handle a million users, so you run fifty servers, and something has to decide which request goes where. That something is a load balancer, and it appears in every design answer you will ever give. Think of a restaurant hostess distributing guests across tables so no waiter drowns.

5. Caching. Databases are slow compared to memory. If a million people request the same homepage feed, computing it a million times is waste. Store the answer once in RAM, serve it a million times in microseconds. Most of "making systems fast" is some version of this idea.

That's the whole first week. Five concepts. Engineers are usually suspicious of how small this list is, and then a month later they tell me it's the reason the rest finally made sense.

Why this order beats the "just watch case studies" approach

Case studies are the best part of learning system design. They're also nearly worthless if you do them first.

When you watch "Design a URL Shortener" without knowing the building blocks, you're memorizing a specific answer. When the constraints change ("what if reads are 100x writes?"), the memorized answer shatters, because you never knew why the cache was there in the first place.

When you do the same case study after learning the blocks, you're doing something completely different: you're practicing selection. You know what a cache does, so the question becomes "does this system need one, and where?" That's the actual skill interviewers grade. It's also the actual skill your job requires.

Same video. Same diagram. Entirely different learning outcome, purely based on what you knew walking in.

The sequence that works

After the first five concepts, the path I give people looks like this:

1. Learn the next 7 building blocks: sharding, replication, consistency models, message queues, CDNs, indexing, and back-of-the-envelope estimation. Same rule as before: understand what problem each one solves, skip the depth.
2. Learn a framework. Requirements, estimation, API, data model, high-level architecture, deep dives, trade-offs. In that order, every time. A framework turns "design Twitter" from a blank-whiteboard panic into a sequence of small, answerable questions.
3. Now do case studies. Start with the URL shortener, then a chat app, then a news feed. Attempt each one yourself, out loud, for 45 minutes before you look at any solution. The gap between your answer and the reference answer is your personalized curriculum.
4. Practice out loud, with a human if possible. System design interviews are conversations, not exams. I've seen engineers who knew plenty fail because the first time they'd ever articulated a trade-off verbally was in the actual interview.

Spread over eight weeks at an hour or two a day, this takes someone from "what's a load balancer?" to holding a coherent 45-minute design conversation. I've written the full week-by-week version, with links for every concept, in my system design roadmap for beginners if you want the detailed plan.

The three failure modes to watch for

After enough repetitions, I can predict how someone will get stuck before they start:

• The memorizer collects architecture diagrams like trading cards and freezes the moment an interviewer changes one constraint. Fix: for every component in a design, force yourself to answer "what breaks if I remove this?"
• The roof-jumper goes straight to "Design WhatsApp" content and drowns in jargon. Fix: the five concepts above, first, no exceptions.
• The passive consumer watches 30 hours of videos, feels fluent, and can't produce a design from a blank page. Fix: never end a study session without explaining what you learned out loud, to a rubber duck if necessary.

All three failure modes share a root cause: consuming content feels like progress, and applying concepts feels like struggle. The struggle is the part that works.

Start smaller than feels reasonable

If you take one thing from this post, make it this: the engineers who get good at system design are not the ones who were smarter. They're the ones who started with embarrassingly basic material and actually practiced it, while everyone else skipped ahead and silently churned.

Client-server. Databases. APIs. Load balancing. Caching. Learn those five this week, explain each one out loud to someone patient, and you'll be ahead of most people grinding case study videos.

And when you're ready for the structured version of the whole journey, the full 8-week roadmap is free, and my System Design Fundamentals course covers the building-blocks phase in one sequenced curriculum if you'd rather not assemble it yourself.

You don't need to be a distributed-systems wizard to start. You need chapter one. Now you have it.

What tripped you up when you started learning system design? I read every comment.