How Long Does It Take to Learn System Design?

Learning the building blocks of system design, the standard parts most large systems share, takes about 20 hours. Handling a 45-minute interview question takes three to six months. That assumes no experience and 40 to 60 minutes a day.

System design is choosing the parts of a large software system and explaining why each one is there. A cache, which keeps a copy of often-read data in memory, is one building block. A load balancer, which spreads incoming requests across many servers, is another.

The range is wide because "learn system design" can mean three different things. It can mean naming the parts, designing a small system, or defending a design under follow-up questions. This article defines those three levels, gives a time for each by starting point, and lists what makes learning faster or slower.

What "learned" means at three levels

A time estimate is only useful if it says what you can do at the end. So the goal comes first. Each level below includes the ones before it.

Level 1: you can name each part and say what problem it solves. You can explain what a cache does and why a system needs one. You can do the same for a replica, which is a second copy of a database on another machine.

You can do it for a message queue, which holds requests until another service is ready to process them. What you still cannot do is decide which parts a new problem needs.

Level 2: you can design a small system under constraints and explain each trade-off. A constraint is a limit placed on the design, like 100 million redirects a day. A trade-off is what you give up to get something else, like fresher data given up for faster reads.

At this level you can start from a blank page and produce a working design. You can also say why each part is there.

Level 3: you can handle an interview question at the level asked and defend your choices. The interviewer changes a constraint, and you change the design and say what the change costs. A senior-level question requires more detailed trade-offs than a junior one, so "the level asked" depends on the role.

How long each level takes

Level 1 takes about 20 hours. That is the length of System Design Fundamentals, a text-based course that teaches one building block per chapter, in order. At 40 to 60 minutes every day, 20 hours takes about three to four weeks.

Level 2 takes another four to six weeks at 40 to 60 minutes a day, after the building blocks. You spend those weeks designing small systems, one constraint at a time, and saying each trade-off out loud.

Level 3 takes three to six months in total from no experience. For an engineer who already runs backend systems for real users, it takes one to two months. The difference is the starting point, which a later section covers.

What level 2 looks like in practice

Take a URL shortener, a service that turns a long link into a short code and redirects visitors to the original. Start with one server and one database. Then add one constraint at a time and see what each one forces.

100 million redirects a day. That is about 1,200 redirects a second, and each one reads the database. So you put a cache in front of the database.

The cost is that a cache can serve an old value. That cost is small here, because a short code always points to the same long link.

Codes must never collide. So you need a generation strategy, for example one counter that returns the next unused number. The cost is that the counter is one more part that can fail.

One database cannot hold all the rows. So you split the rows across several databases by some rule, which is called sharding. The cost is that every lookup must first find the right shard.

That 1,200 a second is estimation, rough arithmetic on the requirements, and the estimation lesson shows the method. If you can add each part, and say its cost as you add it, you are at level 2.

How long it takes by starting point

The table gives the times for four common starting points. Minutes a day is the assumption for each row.

Student or new graduate. You have written programs but never run one for other people. Every block is new, so follow the course order.

Start with the key characteristics of a distributed system, which is a system that runs on more than one machine. Then learn estimation, so that your first design has numbers in it.

One to three years of backend work. You have used a database, a web server, and probably a cache, but someone else chose them. Level 1 is mostly review, so it takes days, not weeks.

Spend the saved time on small designs, said out loud.

Senior engineer moving into design work. You already run backend systems, so most blocks are familiar. The parts you have not learned are usually the ones your systems never needed.

Common ones are partitioning, which splits data across machines, and quorum. Quorum is the minimum number of replicas that must agree before a write is accepted.

One to two months of worked case studies is enough for level 3. A case study is a full design of a real system, worked through step by step.

Anyone with an interview in two weeks. Two weeks is enough to prepare for the interview if you are already at level 2. It is not enough to get to level 2 from nothing.

Study the step-by-step interview method and two or three case studies, then read the blocks you cannot explain.

What makes learning faster

Study the building blocks in order. Each block is easier to understand once you know the problem it answers. The earlier blocks create those problems.

Estimation shows when one server is not enough, and load balancing answers that. Load balancing then creates a new question, where shared data is stored, and caching and replication answer it.

System Design Fundamentals is that 20-hour foundation. Its chapters cover the key characteristics of distributed systems, then caching, partitioning, replication, messaging, and security, in that order.

Every topic chapter ends with flashcards and an adaptive assessment. An adaptive assessment is a quiz that adjusts its questions to your answers. The opening lessons are free to read before buying.

It was formerly called Grokking System Design Fundamentals, and the content is the same.

Build a small version of one part. Write a rate limiter, which rejects requests above a set rate, and set the rate to ten a second. Or write an in-memory cache with an expiry time.

An hour of building teaches the cost of a part better than a chapter of reading does.

Design out loud. Say the design to another person, or record yourself and listen. Saying a trade-off out loud shows you what you do not yet understand, and silent reading does not.

Check recall with flashcards and quizzes. A flashcard is one question with the answer hidden until you try.

Take a CDN, a set of servers near users that serve copies of static files. If you cannot say what problem it solves within ten seconds, reread that chapter.

What makes learning slower

Memorizing reference architectures. A reference architecture is a finished diagram of how a well-known company built one system. Memorizing it teaches the result, not the reasoning.

When an interviewer changes a constraint, the memorized diagram no longer fits.

Starting with Kafka and microservices. Kafka is a distributed messaging system that stores streams of events. Microservices is a way of splitting one application into many small services.

Both solve problems that appear only at a scale a beginner has not reasoned about yet. Learn the single-server design and its limits first. Then the reasons for both become obvious.

Reading without designing. Reading a chapter feels like progress. But the skill is choosing parts under a constraint, and reading never practices the choosing.

Practicing silently. A design you only think through gets no follow-up questions. The interviewer will ask them, so practice answering them from the first design.

Why the time varies so much

System design is a reasoning skill, not a set of facts. The facts, the building blocks, take about 20 hours for anyone.

The reasoning takes as many practice designs as you need. That number depends on what you have already seen at work.

An engineer who has fixed a slow database query already knows what an index is for. An index is a sorted structure a database uses to find rows without scanning the whole table. A student must learn that first and then see a design where it matters.

That is why the starting point matters more than the number of weeks on a plan. Two people on the same plan can reach level 3 months apart, and neither did anything wrong.

Preparing for the interview once the skill exists

Getting to level 2 is learning the skill. Preparing for an interview is a separate and shorter job, because the interview adds a method and a time limit.

How long to prepare for a system design interview gives the preparation time by seniority. A senior engineer needs about two to three weeks, a mid-level engineer four to six, and a junior engineer eight to twelve. Count those weeks after level 2, not instead of it.

Grokking the System Design Interview is the interview course, with a step-by-step method and a chapter on trade-offs. It works real design questions as case studies, like a URL shortener, a news feed, and a chat app. It takes about 20 hours and includes video lessons and a certificate on completion.

Frequently asked questions

How long does it take to learn system design with no experience? About 20 hours to learn the building blocks, then four to six weeks of designing small systems. Handling a 45-minute interview question takes three to six months in total at 40 to 60 minutes a day. The range depends on how many of the parts you have already used at work.

Can you learn system design in one month? Yes, to the level of naming each part and designing a small system, at about an hour a day. One month is not enough to go from no experience to a senior interview question. An engineer with backend experience can get to that level in one to two months.

How many hours a day should you study system design? Forty to 60 minutes a day, most days. Several short sessions teach more than one long weekend session, because each session reviews the last one. Two hours a day is useful only in the last weeks before an interview.

Is system design hard to learn? The parts are not hard. Each one is a plain idea with one problem it solves and one cost it adds. The hard part is choosing between them under a constraint, and that takes practice rather than reading.

Do you need to know how to code before learning system design? Basic programming knowledge is enough. You should know what a database is and roughly how a request gets from a browser to a server. You do not need distributed systems experience.

Related reading

• How Long Does It Take to Prepare for a System Design Interview?
• System Design for Beginners: Where to Start
• Learn system design with no distributed systems experience
• System design building blocks: the parts every scalable system uses
• System design tutorial for beginners
• Learn System Design