Learn System Design From Scratch With No Distributed Systems Experience

You can learn system design from scratch with no distributed systems experience. A distributed system is a system that runs on many machines connected by a network. You do not need to have run one before you learn to design one.

The reason is that system design is a reasoning skill, not a memory of how large companies built their products. Given a vague problem and a few constraints, you make a series of trade-offs and explain each one. A trade-off is a choice where gaining one thing costs another.

This article covers the minimum prerequisites, a first design, and a four-week plan at about 40 minutes a day.

The myth that you need years of large-scale experience

Many engineers open a system design article, see a diagram with twelve boxes and three databases, and close the tab. They believe that system design needs years of running large systems first. It does not.

Plenty of engineers learn it before they have deployed anything bigger than a side project.

System design is not a test of how a ride-sharing app works inside. It is a thinking skill, and that skill does not need experience with a system that serves millions of users. It needs two things: knowing what each part does, and practice at the reasoning.

What you do need is the right starting point and a way to develop judgment without traffic from real users.

The honest minimum prerequisites for system design

You need four things before you start. If any of them is unclear to you, spend a few days on it first. Those few days save weeks of confusion later.

What happens when a web page loads. The browser sends a request, a naming service (DNS) turns the site name into a server address, and the server sends a response. If you can draw those three steps, this prerequisite is done.

The course lesson on what happens when you type a URL into the browser covers the full path.

The two kinds of databases. A relational database stores data in tables and rows and is queried with a language called SQL. A non-relational (NoSQL) database stores documents or key-value pairs instead.

You need to know only that both exist and roughly when to use each. SQL vs NoSQL is the course lesson on that choice.

What an index is. An index is a separate structure that lets a database find a row without reading the whole table. That one sentence is enough to begin.

Rough estimation. Suppose a service gets a million requests a day. A day has 86,400 seconds, so that is about 12 requests a second.

Doing that math out loud matters more than getting it exact. The back-of-the-envelope estimation guide shows the method.

Kubernetes (a tool that runs programs across many machines) and Kafka (a system that moves streams of events between services) are not on the list. Neither is the CAP theorem, a rule about the choice a system must make when the network fails.

Beginners start on those far too early. You will learn each one when a design needs it.

The mindset shift: learn the problem each part solves and the problem it creates

Beginners often learn system design by memorizing answers. How is a photo feed built, how does a chat app deliver messages. They memorize a dozen reference architectures and feel productive.

A reference architecture is a published design of how one company built one product. Then the beginner is asked to design something slightly different, and none of the memorized designs apply.

The fix is to learn reasoning instead of answers. For every part you study, learn two things. What problem does it solve, and what new problem does it create?

A cache is a small, fast store that keeps copies of recent results. It makes reads fast, which solves a latency problem (latency is the time a request waits for its response). It can also return an old copy after the database has changed, which is a staleness problem.

A queue is a store that keeps messages until a worker reads them. During a sudden rise in traffic, work waits in the queue instead of overloading the server. That solves a load problem, but it adds delay and new ways to fail.

Once you think in those pairs, you can design systems you have never seen. That is the whole skill.

Your first design: a URL shortener

Reading designs teaches you to recognize them. Making one teaches you to produce them. So pick a first system that is small enough to finish in one session but still teaches the core ideas.

The classic choice is a URL shortener. It turns a long link into a short code and redirects anyone who opens the code.

The method is to start with the simplest possible version, then add one constraint at a time.

Version 1, the simplest design. One server and one database. A user submits a long URL, the server makes a short code, stores the pair, and redirects on lookup.

It works for ten users. You have designed a system.

Add a constraint: 100 million redirects a day. That is about 1,160 redirects a second, and each one reads the database. Slow reads are the problem, and a cache is the answer.

So you put a cache in front of the database, and with it you get the staleness problem from the previous section.

Add another: short codes must never collide. A collision is two long URLs receiving the same short code. Now you must choose how codes are generated.

The options are a random code with a uniqueness check, a counter, or a hash of the long URL. A hash is a fixed-length value computed from an input. Each option has a cost.

Add one more: one database server cannot hold all the data. Now you must split the table across several machines. That is sharding, and this is the easiest way to learn it.

Each constraint required exactly one new idea. You learned that idea because the design needed it, not because a book listed it. Real systems get their parts the same way.

The URL shortening service design covers this same problem in full.

How to develop intuition without a production system

A production system is one that serves real users, and you cannot test ideas on one yet. Intuition here means a quick, correct guess about which part a design needs, and these three habits give you that.

Read with a question. When you read how a real system works, stop at each part. Ask what would fail if that part were removed.

If you can answer, you understand the part. If you cannot, that is the next thing to study.

Make small versions. A rate limiter is a part that caps how many requests one client may make in a period. Writing one is a weekend project, and so is a simple key-value cache or a basic message queue.

A tiny working version teaches more than reading about the large one.

Reason about apps you already use. Each time you use an app, ask one design question about it.

A like count that is slightly wrong is probably a cache. A message that goes out after you were offline is probably a queue.

A four-week plan at 40 minutes a day

This plan assumes about 40 minutes a day, six days a week, and the four prerequisites above. Forty focused minutes a day teach more than one long weekend.

Week 1: one building block a day. A load balancer is a server that sends each incoming request to one of several application servers. Replication keeps a copy of the same data on more than one server.

For each block, write three sentences: what it solves, what it costs, and when to use it.

System Design Fundamentals teaches these blocks one per chapter, in order, as a text-based course of about 20 hours. It was formerly called Grokking System Design Fundamentals, and it needs only basic programming knowledge.

Week 2: your first systems. Add constraints to the URL shortener one at a time, as shown above. Then do the same with a pastebin (a site that stores a block of text at a short link) or a basic image host.

Week 3: a bigger system. You will stop at points where you do not know the next step, and that is expected. Each of those points is the next topic to study.

Week 4: practice out loud. Say every decision aloud, as if explaining it to a colleague. If you cannot explain a choice, you have not learned it yet.

After four weeks you will not be a senior architect. You will no longer be a beginner, and you will know how to continue.

Beginner mistakes to skip

Starting with the impressive architecture. Microservices split one application into many small services that communicate over a network. Adding microservices and Kafka on day one is a mistake.

Start simple, and justify every addition with a constraint.

Memorizing reference designs. The question you are asked will differ from the design you memorized. Learn the reasoning that produced each design instead.

Studying parts you never use. Distributed consensus is the problem of getting several servers to agree on one value. You do not need it to design a URL shortener, so learn a part when a problem needs it.

Practicing silently. System design is a communication skill. If you only think a design through in your head, you are practicing the wrong thing.

Skipping the math. "It scales" is not an answer. Rough numbers are what justify each choice.

Where this post ends and the longer roadmap begins

This post ends at week four. The next step is a longer plan organized by career level.

System Design for Beginners: Where to Start gives an eight-week roadmap that begins where these four weeks end. The Learn System Design page collects the guides in order by career level.

When the goal is an interview, Grokking the System Design Interview is the original interview course. It teaches a step-by-step method and works real problems as case studies, including a URL shortener and a chat app.

You can start today with no experience: pick the URL shortener, design the simplest version, then add a constraint.

Frequently asked questions

Can I learn system design with no distributed systems experience? Yes. System design is a reasoning skill: choose between options under a constraint and explain the cost of each. Experience with large systems helps later, but many engineers learn the skill before they have run one.

What are the prerequisites for learning system design? Four things: how a web page loads, the two kinds of databases, what an index is, and rough math. Rough math means turning a million requests a day into about 12 a second without a calculator. Basic programming knowledge covers the rest.

What should my first system design project be? A URL shortener, started as one server and one database. Then add one constraint at a time: a high redirect rate, codes that never collide, and data too large for one server. Each constraint teaches exactly one idea.

How long does it take to learn system design from scratch? About four weeks at 40 minutes a day for a beginner foundation, if you already have the four prerequisites. After that you can design a small system under constraints and explain each trade-off. How long does it take to learn system design gives the time by starting point.

Is system design only useful for interviews? No. Making and defending trade-offs is exactly what you do when designing real systems at work. Interview preparation is a concentrated version of the same skill.

Related reading

• System Design for Beginners: Where to Start
• How Long Does It Take to Learn System Design?
• System Design Building Blocks: The Components Every Scalable System Uses
• System Design Fundamentals: 25 Core Concepts Explained for Beginners
• Back-of-the-Envelope Estimation for the System Design Interview
• The 4 Basic Pillars of System Design