System Design Roadmap
A structured roadmap for learning system design, from scaling basics and data systems to reliability patterns, distributed trade-offs, and real-world architecture problems.
What is System Design?
System design is the practice of deciding how a software system should behave once it runs in the real world. It includes how requests move through services, how data is stored and retrieved, how components communicate, and how the system behaves when traffic grows or dependencies fail.
Why it matters
System design matters because production systems eventually hit the limits of simple assumptions. More users, more data, more teams, and more failure modes force you to think about scale, latency, consistency, resilience, and cost. Learning it helps you make better architectural choices in interviews and in real engineering work.
After this roadmap, you should be able to reason about scalable architectures more confidently, explain trade-offs in distributed systems clearly, and approach system design interviews or production design work with stronger architectural judgment.
The Roadmap
This roadmap takes you from core scaling concepts to the patterns and trade-offs used in real distributed systems, with structured overviews, deep topic coverage, and design-focused practice.
What to learn next?
Choose the next roadmap that expands the skills you just built and moves you closer to your saved preparation goal.
Frequently asked questions
What is System Design?
System Design is the process of defining architecture, components, and data flows for software systems that must scale. It covers load balancing, databases, caching, message queues, and distributed consistency.How long does it take to learn System Design?
The duration depends entirely on your selected goals and the amount of time you can commit each week. This roadmap is highly adaptive; for example, if you set a high weekly hour goal to fast-track your learning, you can cover the basics in 2–3 weeks. However, for a deep dive into senior-level topics like distributed transactions and consensus, most learners find that an 3-week pace allows for the best retention and practical mental modeling.Do I need to learn everything in this roadmap?
Not necessarily. What you need to master depends entirely on your specific career goals, the role you are targeting, and the level of expertise you want to achieve. For example, a Frontend Engineer might focus heavily on Caching and API design, while a Data Engineer would prioritize NoSQL internals and Message Queues. This roadmap is designed to be modular so you can deep-dive into the areas most relevant to your path.What will I learn in the System Design roadmap?
You will learn scaling (vertical/horizontal), CAP theorem, consistency models, capacity planning, RDBMS and NoSQL, caching strategies, networking (DNS, load balancing, CDN), APIs (REST, GraphQL, gRPC), message queues, Kafka, CQRS, microservices, distributed transactions (2PC, Saga), consensus (Paxos, Raft), fault tolerance, rate limiting, security, observability, and real-world designs (URL shortener, Pastebin, rate limiter, chat, news feed, notification system).Is System Design important for interviews?
Yes. Senior engineering and architect roles expect you to discuss system design. You need to estimate capacity, sketch components, and justify trade-offs. This roadmap prepares you for that.What are common system design interview questions?
Common questions include: design a URL shortener, design a chat app (e.g. WhatsApp), design a news feed (e.g. Twitter), design a rate limiter, design a notification system, and design a distributed key-value store. This roadmap covers all of these.How is system design different from coding interviews?
Coding interviews test algorithms and implementation. System design interviews test your ability to architect scalable systems—you discuss high-level components, trade-offs, capacity estimation, and draw diagrams rather than write code.What is the best way to learn System Design?
Follow this roadmap in order, complete the preparation steps, and practice designing systems on paper or a whiteboard. Use the curated resources (System Design Primer, Grokking, Martin Fowler) and build mental models for each concept.What is the CAP Theorem and why does it matter?
The CAP Theorem states that a distributed system can only provide two out of three guarantees: Consistency, Availability, and Partition Tolerance. In reality, network partitions are inevitable, so designers must usually choose between Consistency (CP) or Availability (AP) during a failure. Understanding this helps you choose the right database for your specific use case.What is the difference between horizontal and vertical scaling?
Vertical scaling (Scaling Up) means adding more power (CPU, RAM) to an existing server, which has a physical limit. Horizontal scaling (Scaling Out) means adding more servers to your pool. Modern large-scale systems almost always prefer horizontal scaling because it is more resilient and theoretically limitless.When should I choose NoSQL over a Relational Database?
Choose RDBMS (SQL) when you need ACID compliance, complex joins, and structured data (e.g., financial systems). Choose NoSQL when you need to handle massive volumes of unstructured data, require a flexible schema, or need extreme horizontal write scalability (e.g., social media feeds or real-time analytics).What is a "Single Point of Failure" (SPOF)?
An SPOF is any part of a system that, if it fails, will stop the entire system from working. Examples include a single database instance or a lone load balancer. System design aims to eliminate SPOFs by introducing redundancy, such as using database replicas and clustered services.How do I handle "Hot Keys" in a distributed cache?
Hot keys occur when a specific piece of data (like a celebrity profile) is requested so frequently that it overwhelms a single cache node. Solutions include adding local in-memory caching on the application servers, further sharding the data, or using an "Origin Shield" to consolidate requests.What is Backpressure in system design?
Backpressure is a strategy where a downstream service tells an upstream producer to slow down because it is being overwhelmed with requests. Instead of crashing, the system pushes back on the traffic, allowing it to process the current load safely before accepting more work.