The 12-Week System Design Interview Roadmap for Software Engineers
How to Teach Yourself System Design in Twelve Weeks Using Online Resources, in the Exact Order That Builds Understanding Rather Than Confusion
What This Blog Will Cover
Why order matters in system design
Weeks one through four foundations
Weeks five through eight core patterns
Weeks nine through twelve advanced topics
How to practice alongside the curriculum
Most engineers who try to study system design on their own follow the same pattern. They find a list of topics, pick one that sounds important, read about it, pick another, watch a video, jump to a third, and six weeks later they have a loose collection of half-understood concepts but no ability to actually design a system.
The problem is not effort. It is order and structure.
System design is a subject where concepts build on each other, and studying them in the wrong order means constantly encountering ideas that reference things you have not learned yet.
Without a solid base of foundational concepts, everything more advanced sits on unstable ground and fails to stick.
The other problem is that most resource lists are not curricula. They are inventories.
A list of thirty articles and twenty videos is not a study plan.
A study plan has sequence, pacing, and a way to convert reading into usable skill, which is practice.
This curriculum solves both problems. It gives you twelve weeks of structured study, organized in the specific order that builds understanding correctly, using only free resources that are publicly available.
Each week has a clear focus, named resources, and a practice task that converts reading into skill.
The goal is not to expose you to every topic in system design but to give you a complete, coherent foundation that lets you reason through any problem you face.
How to Use This Curriculum
A few principles will make this curriculum far more effective than following it mechanically.
Practice is not optional: Every week includes a practice task, and skipping it in favor of reading more is the most common mistake. Reading builds familiarity. Practice builds skill. The interview evaluates skill, so the practice tasks are the most important part of each week, not the reading.
Speak out loud: Every practice problem in this curriculum should be worked out loud, not in writing and not silently. The interview requires you to think and communicate simultaneously, and this skill only develops by doing it. Speaking out loud while practicing feels awkward at first and becomes natural after a few weeks of deliberate effort.
Depth over breadth: This curriculum does not cover everything in system design. It covers the concepts that matter most in the order that makes them make sense. Resisting the urge to chase every interesting topic you encounter is what allows you to finish twelve weeks with a real foundation rather than a wider inventory of things you half-understand.
Weekly review: Spend the last day of each week reviewing what you covered and identifying the one thing you are least confident about. That uncertainty is what to address before moving on, because unresolved gaps compound as the curriculum advances.
Phase 1: Foundations (Weeks 1 to 4)
Week 1: How the Web Works and What System Design Actually Is
Focus: Understanding the basic model of client-server communication, what a system design interview actually evaluates, and the framework you will use for every problem.
Why this week first: Before studying any specific component or pattern, you need a clear mental model of the problem space. Engineers who skip this week and go straight to databases or caching often cannot explain why those components exist or what problem they solve, which produces shallow answers in interviews.
What to study:
Start with how the web actually works at a high level. The key concepts are clients sending requests to servers, servers sending responses back, and the stateless nature of this exchange. Understand what happens when you type a URL into a browser, from the DNS lookup through the TCP connection through the HTTP request and response. This is the foundation of everything that follows.
Then understand what system design interviews actually evaluate.
They do not test how many components you know.
They test whether you can drive an ambiguous problem to a working architecture while narrating your reasoning and making trade-offs explicit. Reading What the Interviewer Is Actually Writing Down While You Talk before you do anything else this week reframes your entire preparation, because it tells you the goal is judgment and communication, not memorization.
Finally, learn and memorize the framework you will use for every practice problem: clarify requirements, estimate scale, define the API and data model, design the high-level architecture, go deep on the hard parts, and address failure and bottlenecks.
The First 15 Minutes of a System Design Interview walks through exactly how to spend each phase of this opening and is the most immediately actionable read of the week.
Free resources:
“How the Web Works” on MDN Web Docs covers the request-response cycle, DNS, and HTTP clearly
The Grokking System Design repository on GitHub is the most comprehensive free resource in the field. Bookmark it now and return to it throughout the twelve weeks, since it covers nearly every topic in this curriculum with diagrams and worked examples
Paid resource:
Grokking the System Design Interview covers the framework applied to real interview problems with full worked solutions. If you invest in one paid resource this curriculum, this is it
Practice task: Write a one-page explanation of what happens when a user logs into a web application, covering the request from the browser through the server response. This forces you to make the web’s basic model concrete before adding complexity on top of it.
Week 2: Scalability, Load Balancing, and Statelessness
Focus: Understanding how systems handle growth, how traffic is distributed, and why stateless services are the foundation of horizontal scaling.
Why this week second: Scalability is the underlying goal of almost everything in system design. Understanding it in week two means every concept you learn afterward can be understood as a tool for achieving it.
What to study:
Cover the two ways to scale: vertically, by making one machine bigger, and horizontally, by adding more machines.
Understand why horizontal scaling is the foundation of large systems and why it requires stateless services, meaning servers that hold no client-specific state between requests so that any server can handle any request.
Study load balancers in depth: what they do, how different algorithms (round robin, least connections, consistent hashing) decide where to send traffic, and why they are necessary for horizontal scaling.
Understand health checks and why a load balancer must stop sending traffic to an unhealthy server.
The Scalability section of the Grokking System Design GitHub repository covers vertical versus horizontal scaling, load balancers, and statelessness with diagrams that make the concepts concrete.
Work through that section alongside 12 Scalability Bottlenecks That Break Otherwise Good System Design Answers, which shows where designs built on these concepts most commonly fail. Reading both together, the theory and the failure modes, gives you a more complete understanding than either alone.
Load shedding is one of the most underrated topics in scalability and one interviewers notice when you raise it proactively.
Practice task: Work the URL shortener problem using the framework from week one.
Focus only on the scaling decisions: what would you scale first, how would you make the servers stateless, and where would state live?
Speak the answer out loud for thirty minutes.
Week 3: Databases, SQL vs NoSQL, and Caching
Focus: Understanding the two database families, what drives the choice between them, and how caching protects the database and makes reads fast.
Why this week third: Almost every system design problem involves data storage and retrieval, and the database choice plus the caching strategy together determine how the system performs under read-heavy load, which is most systems.
What to study:
Cover relational databases: tables, schemas, relationships, joins, and ACID transactions. Understand when relational data, structured, highly related, needing transactions, is the right fit.
Cover NoSQL databases by family: key-value stores, document stores, wide-column stores, and graph databases.
The clearest single resource for this decision is PostgreSQL vs. DynamoDB vs. Cassandra: A System Design Decision Tree, which walks through the exact questions to ask and maps each answer to a database choice. It is more useful than a general explanation because it gives you a decision process rather than just definitions.
Once you have the database choice covered, read Database Indexing Guide. This is an important post for any engineer who has ever said “I’ll just add an index” without thinking through the write cost.
The depth of your indexing answer in an interview is one of the clearest signals of how deeply you understand databases.
Then cover caching thoroughly, using the caching section of the Grokking System Design GitHub repository for the patterns.
Follow it immediately with Hot Keys, Cache Stampedes, and Thundering Herds: The Hidden Limits of Redis, which covers the failure modes that shallow caching knowledge misses entirely.
A candidate who can name the cache-aside pattern and also explain how a stampede forms and how to prevent it is signaling a level of depth that most cannot match.
Practice task: Work the Twitter timeline problem, focusing specifically on the data layer.
What database would you use for tweets, for user relationships, for the timeline itself?
Where would you cache?
Spend forty-five minutes on it out loud, and spend fifteen minutes afterward writing down every decision you made and the trade-off you would name for each.
Week 4: Replication, Sharding, and Consistency
Focus: Understanding how databases scale beyond one machine through replication and sharding, and the consistency trade-offs that distributed data introduces.
Why this week fourth: Week three established the database and caching layer. Week four is where you learn what happens when one database is not enough, which is where most scalability problems actually live.
What to study:
Cover replication: keeping copies of data on multiple machines. Understand the leader-follower model, where one machine handles writes and replicas serve reads.