System Design Roadmap 2026 | From Zero to Interview-Ready

System design is the round that separates mid-level engineers from senior ones in placement interviews. Companies like Google, Amazon, Microsoft, Flipkart, and Goldman Sachs dedicate entire interview rounds to it, and most freshers walk in completely unprepared because system design is not taught in college.

The good news is that system design is learnable. It is not about memorizing correct answers. It is about learning to think through problems the way engineers at large companies do, making deliberate trade-offs, and communicating your reasoning clearly. This roadmap gives you a structured path to get there, with free resources at every step.

What This Roadmap Covers

  • Core concepts every system design interview tests
  • Key building blocks: databases, caching, load balancers, CDNs, message queues
  • High-level design: architecture patterns and real-world system walkthroughs
  • Low-level design: OOD, SOLID principles, and design patterns
  • Distributed systems: CAP theorem, consistency, consensus
  • A curated resource library with free YouTube playlists, GitHub repos, and books
  • 100+ system design interview questions organized by category

If you are looking for a paid deep-dive, ByteByteGo by Alex Xu is the best structured course available. Everything else in this roadmap is free.

Phase 1: Core Concepts (Start Here)

Before you design any system, you need to understand what properties good systems have and what trade-offs you are making when you choose one approach over another.

Scalability

Scalability means your system can handle more load without breaking or slowing down significantly. There are two ways to scale.

Vertical scaling means adding more resources to a single machine: more RAM, faster CPU, bigger disk. It is simple to implement but has a hard limit. You cannot keep adding hardware to one machine forever, and it creates a single point of failure.

Horizontal scaling means adding more machines and distributing the load across them. It is more complex since now you need coordination between machines, but it is how every large system at scale actually works. When Amazon adds servers during Diwali sales, that is horizontal scaling.

The key question to always ask yourself in an interview: "How does this system behave when load doubles? When it increases 10x?"

Resources:

Availability and Reliability

Availability is the percentage of time a system is operational. A system with 99.9% availability is down for about 8.7 hours per year. A system with 99.99% availability is down for under an hour. Companies like Amazon and Google target five nines (99.999%), which allows less than 5.5 minutes of downtime per year.

Reliability means the system does what it is supposed to do, consistently, even when some parts fail. Reliability is achieved through redundancy: having backup components that take over when primary ones fail.

The two concepts are related but different. A system can be highly available (always responding) but unreliable (giving wrong answers). You want both.

Latency vs Throughput

Latency is how long a single request takes. Throughput is how many requests your system can handle per second. These are not the same thing, and optimizing for one can hurt the other.

A database query might have low latency for one user, but if 10,000 users hit it simultaneously, throughput becomes the bottleneck. Understanding this distinction is important for every caching and database design decision.

CAP Theorem

The CAP theorem states that in a distributed system, you can only guarantee two of three properties at the same time: Consistency, Availability, and Partition Tolerance.

Consistency means every read gets the most recent write. Availability means every request gets a response (though it may not be the most recent data). Partition Tolerance means the system keeps working even when network failures cause some nodes to lose communication.

In practice, network partitions always happen in distributed systems, so you always need Partition Tolerance. The real choice is between Consistency and Availability when a partition occurs. Databases like HBase choose consistency. Cassandra and DynamoDB choose availability. SQL databases typically choose consistency.

Resources:

Consistency Models

Strong consistency means every read sees the latest write. This is what a SQL database gives you within a transaction.

Eventual consistency means reads may return stale data temporarily, but the system will eventually converge to the correct state. DNS is a classic example: when you update a DNS record, it takes time to propagate across servers, but eventually everyone sees the new value.

Most large distributed systems use eventual consistency because it allows much higher availability and performance. The trade-off is that your application code has to handle the case where data might be slightly stale.

Phase 2: Key Building Blocks

These are the components that appear in almost every system design interview. Know each one deeply, including its trade-offs.

Databases: SQL vs NoSQL

SQL databases (PostgreSQL, MySQL, SQLite) store data in tables with relationships. They give you ACID guarantees: Atomicity, Consistency, Isolation, Durability. Use SQL when your data has a clear structure, relationships matter, and you need transactions. A bank's transaction ledger should be SQL. A user profile with structured fields should be SQL.

NoSQL databases come in several flavors:

Document stores (MongoDB, Firestore): store JSON-like documents. Good for flexible schemas where each record may have different fields. Good for content management systems, catalogs.

Key-value stores (Redis, DynamoDB): blazing fast lookups by key. Used for caching, session management, rate limiting.

Column-family stores (Cassandra, HBase): designed for massive write throughput and time-series data. Used by Instagram, Netflix, Uber for event data.

Graph databases (Neo4j): model relationships as first-class citizens. Used for social networks, recommendation engines.

The wrong answer in an interview is picking one without explaining why. The right answer is explaining the trade-offs and choosing based on the system's specific requirements.

Resources:

Caching

Caching stores a copy of frequently accessed data in a faster storage layer so you do not have to recompute or re-fetch it every time. It is one of the highest-impact optimizations in system design.

Where to cache: in-memory on the application server (fastest, but lost on restart), in a distributed cache like Redis or Memcached (shared across servers, survives restarts), at the CDN level (for static assets), or at the database query level (for expensive queries).

Cache eviction policies determine what gets removed when the cache is full.

  • LRU (Least Recently Used): remove the data not accessed for the longest time
  • LFU (Least Frequently Used): remove the data accessed the fewest times
  • TTL (Time to Live): expire cached data after a fixed time period

Cache invalidation is the hardest part. When should you update or delete cached data? Strategies include cache-aside (application manages cache), write-through (write to cache and DB simultaneously), and write-back (write to cache first, sync to DB later).

Watch out for cache stampede: when a popular cache entry expires and thousands of requests hit the database simultaneously before the cache is repopulated. Solutions include probabilistic early expiration and cache locking.

Resources:

Load Balancers

A load balancer sits in front of your servers and distributes incoming requests across them. Without one, all traffic hits a single server until it collapses.

Algorithms for distributing load:

  • Round Robin: requests go to servers in rotation. Simple, but ignores server load.
  • Least Connections: requests go to the server with the fewest active connections. Better for long-running requests.
  • Weighted Round Robin: servers with more capacity get proportionally more requests.
  • IP Hashing: the same client always goes to the same server. Useful when session state is stored on the server.

Layer 4 vs Layer 7 load balancing. Layer 4 load balancers work at the TCP level and route based on IP and port. They are fast but cannot inspect request content. Layer 7 load balancers work at the HTTP level and can route based on URL, headers, cookies. They are more flexible but add slight latency.

Nginx, HAProxy, and AWS ELB are common load balancer choices. Most modern systems use Layer 7.

Resources:

Content Delivery Networks (CDN)

A CDN is a geographically distributed network of servers that cache and serve static content (images, videos, CSS, JavaScript) from locations close to users. When a user in Mumbai requests an image from a server in the US, latency is 200ms+. When a CDN edge server in Mumbai serves that same image, latency drops to under 10ms.

CDNs also help with traffic spikes since cache hits do not reach your origin server at all. This is why YouTube can serve billions of video views without its origin servers melting down.

Push CDN vs Pull CDN: with a push CDN you upload content to the CDN manually. With a pull CDN the CDN fetches content from your origin on the first request and caches it. Pull CDNs are more common for web applications.

CloudFront (AWS), Cloudflare, Akamai, and Fastly are the major CDN providers.

Message Queues

Message queues decouple producers (services that create events) from consumers (services that process them). Instead of Service A calling Service B directly and waiting for a response, A puts a message on a queue and B processes it whenever it is ready.

This gives you:

  • Async processing: A does not block waiting for B
  • Buffer for traffic spikes: if B is slow, messages queue up instead of requests timing out
  • Retry on failure: if B crashes, messages are not lost; they can be retried
  • Fan-out: one message can trigger multiple consumers

Kafka is a distributed log, not a traditional queue. It is built for high-throughput event streaming. Messages are retained for a configurable period, so consumers can replay history. Used by LinkedIn, Uber, and Netflix for event streaming at massive scale.

RabbitMQ is a traditional message broker. Better for task queues, routing, and request-response patterns. Simpler than Kafka for straightforward use cases.

AWS SQS is a managed queue service. Good choice on AWS when you want zero operational overhead.

Resources:

APIs: REST vs GraphQL vs gRPC

REST is the most common API style. Resources are represented as URLs, and HTTP methods (GET, POST, PUT, DELETE) define operations. Simple, widely understood, easy to cache. The downside is over-fetching (getting more data than you need) and under-fetching (needing multiple requests to get all the data you want).

GraphQL lets clients specify exactly what data they need in a single request. Eliminates over-fetching and under-fetching. Popular with mobile apps where bandwidth matters. The downside is complexity: caching is harder, and malicious queries can be expensive.

gRPC uses Protocol Buffers instead of JSON. Strongly typed, much faster serialization, supports streaming. Used for internal service-to-service communication where performance matters. Not suitable for browser clients without a translation layer.

Resources:

Phase 3: High-Level Design

High-level design (HLD) is about the big picture: how do the major components of your system fit together?

Monolithic vs Microservices

A monolithic application has all its functionality in one deployable unit. The database layer, business logic, and presentation layer are all in one codebase. This is not inherently bad. Most successful startups start as monoliths because they are simpler to build, test, and deploy.

Microservices split the application into small, independently deployable services, each responsible for one domain. The payment service, user service, order service, and notification service all run separately and communicate over APIs or message queues.

Microservices give you:

  • Independent deployment and scaling of each service
  • Technology diversity (each service can use the best language/database for its job)
  • Isolated failures (one service crashing does not take down others)

Microservices cost you:

  • Distributed system complexity (network failures, latency, distributed transactions)
  • Operational overhead (you now manage dozens of deployments)
  • Testing complexity (integration tests across services are hard)

The correct interview answer is: start with a monolith, break into microservices when you hit real scaling pain at specific boundaries.

Resources:

Event-Driven Architecture

In an event-driven system, services communicate by publishing and consuming events rather than calling each other directly. When a user places an order, the Order Service publishes an "OrderPlaced" event. The Inventory Service, Notification Service, and Analytics Service all listen for that event and react independently.

This creates very loose coupling. Services do not need to know about each other. Adding a new service that reacts to an existing event requires zero changes to existing services.

The downside is that tracing the flow of an operation across multiple event handlers becomes much harder. Debugging requires distributed tracing tools like Jaeger or Zipkin.

CQRS and Event Sourcing

CQRS (Command Query Responsibility Segregation) separates the read and write models of your data. Writes go through one model (commands), reads through another (queries). This lets you optimize each independently: your write model can be normalized SQL, your read model can be a denormalized cache optimized for specific queries.

Event Sourcing stores all state changes as an immutable sequence of events rather than just the current state. Instead of storing "balance: 5000", you store "Deposited 1000, Withdrew 500, Deposited 4500". The current state is derived by replaying events. This gives you a complete audit trail and the ability to reconstruct state at any point in time.

Designing Real Systems

The best way to learn HLD is to walk through real systems. Do not just read theory.

Design a URL Shortener (TinyURL) Key decisions: ID generation (base62 encoding vs hash), database choice (SQL for simplicity, NoSQL for scale), caching (cache popular short URLs in Redis), redirection (301 permanent vs 302 temporary redirect and why it matters for analytics).

Design a Ride-Sharing System (Uber) Key decisions: matching algorithm (geospatial indexing with quadtrees or geohash), real-time location updates (WebSockets), surge pricing calculation, trip database design, notification delivery.

Design a Video Streaming Service (YouTube/Netflix) Key decisions: video upload pipeline (chunk uploads, transcoding to multiple resolutions), CDN for delivery, recommendation engine, comment system, view count at scale (approximate counting with HyperLogLog).

Design a Messaging System (WhatsApp) Key decisions: message delivery guarantees (at-least-once vs exactly-once), offline message storage, end-to-end encryption architecture, group messaging fan-out, last-seen and typing indicators.

Design a News Feed (Twitter/Instagram) Key decisions: fan-out on write vs fan-out on read, handling celebrity accounts (millions of followers), feed ranking, infinite scroll pagination.

Resources:

Phase 4: Low-Level Design

Low-level design (LLD) is asked in interviews as a separate round at most companies. It tests whether you can translate a feature into clean, well-structured code using object-oriented design principles.

SOLID Principles

SOLID is a set of five design principles that make object-oriented code more maintainable and scalable.

Single Responsibility Principle: a class should have exactly one reason to change. A UserService should handle user logic, not also send emails and generate reports. If it does multiple things, split it.

Open/Closed Principle: code should be open for extension but closed for modification. Add new behavior by adding new classes, not by editing existing ones. This is why you use inheritance and interfaces instead of if-else chains.

Liskov Substitution Principle: a subclass should be substitutable for its parent class without breaking the program. If your Square extends Rectangle and overrides setWidth to also set height, you break programs that use Rectangle. That is a Liskov violation.

Interface Segregation Principle: do not force a class to implement methods it does not need. Create smaller, specific interfaces instead of one fat interface.

Dependency Inversion Principle: depend on abstractions, not concretions. Your OrderService should depend on a PaymentProcessor interface, not a specific StripePaymentProcessor. This makes testing and swapping implementations easy.

Design Patterns

Design patterns are reusable solutions to common software design problems. Learn these eight patterns thoroughly for LLD interviews:

Creational Patterns (object creation)

  • Singleton: ensures only one instance of a class exists. Used for database connection pools, configuration managers. Watch out for multithreading issues.
  • Factory: creates objects without specifying the exact class. A NotificationFactory can return EmailNotification or SMSNotification based on input.
  • Builder: constructs complex objects step by step. Used when an object has many optional parameters.

Structural Patterns (how classes are composed)

  • Decorator: adds behavior to objects dynamically without changing their class. Used in Java's I/O streams, middleware in web frameworks.
  • Adapter: makes incompatible interfaces work together. Like a power adapter for different socket standards.
  • Proxy: controls access to another object. Used for lazy initialization, logging, access control.

Behavioral Patterns (how classes communicate)

  • Observer: one object notifies a list of dependent objects when its state changes. Used in event systems, MVC frameworks.
  • Strategy: defines a family of algorithms and makes them interchangeable. A SortStrategy can swap between QuickSort and MergeSort at runtime.

Common LLD Interview Problems

  • Design a Parking Lot system
  • Design a Library Management System
  • Design an Elevator System
  • Design a Chess game
  • Design a Hotel Booking System
  • Design a Vending Machine
  • Design a Splitwise (expense sharing) system
  • Design an Amazon Locker system
  • Design a Snake and Ladder game
  • Design a Movie Ticket Booking System (BookMyShow)

For each problem, think about: what are the entities? What are the relationships between them? What are the behaviors? Which design patterns apply?

Resources:

Phase 5: Distributed Systems Deep Dive

This phase is relevant if you are targeting FAANG, BFSI quant roles, or senior engineering positions.

Consistency and Replication

When data is replicated across multiple nodes, keeping it consistent is non-trivial. There are three replication strategies:

Single-leader replication: one node is the primary and accepts all writes. Followers replicate from the primary. Simple, but the leader is a bottleneck and a single point of failure.

Multi-leader replication: multiple nodes accept writes. Used for multi-datacenter setups. The complexity is resolving write conflicts when two leaders accept conflicting updates simultaneously.

Leaderless replication: any node can accept reads and writes. Cassandra uses this. Consistency is maintained through quorum: a write is successful only if a majority of nodes acknowledge it.

Distributed Consensus

How do distributed systems agree on a single value when nodes can fail and messages can be lost? This is the consensus problem.

Paxos was the first practical consensus algorithm but is notoriously difficult to implement correctly. Most systems use Raft instead, which achieves the same guarantees but is designed to be more understandable. Raft is used by etcd (which powers Kubernetes) and CockroachDB.

The key idea: elect a leader, have the leader coordinate all decisions, handle leader failure by electing a new one.

Distributed Transactions

A distributed transaction modifies data across multiple services or databases atomically: either all changes commit or all roll back. This is hard because network failures can leave things in inconsistent states.

Two-Phase Commit (2PC): a coordinator asks all participants to prepare, then tells them all to commit. If any participant cannot prepare, the coordinator tells everyone to abort. The problem: if the coordinator crashes after sending "prepare" but before sending "commit", participants are stuck.

Saga pattern: instead of a single transaction, you use a sequence of local transactions with compensating transactions to undo each step if something fails. Used by companies that have moved away from distributed transactions entirely.

Rate Limiting

Rate limiting protects your system from being overwhelmed by too many requests from a single client. It is also used to enforce pricing tiers in APIs.

Token Bucket: each client has a bucket that fills with tokens at a fixed rate. Each request consumes a token. If the bucket is empty, the request is rejected. Allows short bursts up to the bucket size.

Leaky Bucket: requests enter a queue and are processed at a fixed rate. Smooths out bursts but adds latency.

Fixed Window: count requests per fixed time window (e.g., 100 requests per minute). Simple but susceptible to burst attacks at window boundaries.

Sliding Window Log: track the timestamp of every request in a rolling window. More accurate but memory-intensive.

Resources:

How to Approach a System Design Interview

Most candidates jump directly to the solution. That is wrong. The interview is testing your thinking process as much as the solution itself.

Step 1: Clarify requirements (3 to 5 minutes). Ask about scale: how many daily active users? What are the read/write ratios? What are the latency requirements? Is this a global system or regional? What consistency guarantees are needed? Getting these numbers right changes the entire design.

Step 2: Estimate scale (2 to 3 minutes). Back-of-envelope calculations. If you have 100 million daily users sending one message per day, that is roughly 1,200 writes per second. At 1KB per message, that is 1.2 MB/s write throughput. These numbers guide your technology choices.

Step 3: Define the API (2 to 3 minutes). What endpoints does the system expose? What are the inputs and outputs? This clarifies the scope and gives you a concrete contract to design around.

Step 4: High-level design (10 minutes). Draw the major components and how data flows between them. Do not get stuck in detail yet.

Step 5: Deep dive on critical components (10 to 15 minutes). The interviewer will usually guide you here. Database schema, caching strategy, handling hotspots, message queue design.

Step 6: Discuss trade-offs and improvements. What are the weaknesses of your design? What would you change with more time or different constraints?

Complete Resource Library

Free YouTube Channels

  • Gaurav Sen: the best starting point for system design concepts in India. Watch all his system design videos before anything else.
  • ByteByteGo: animated explanations of system design concepts. Extremely high quality.
  • Arpit Bhayani: deep engineering content on distributed systems, databases, and real company architectures.
  • Hussein Nasser: deep dives into protocols, databases, and backend engineering. Great for understanding the internals.
  • CodeKarle: system design case studies in interview format.
  • Tech Dummies: practical system design for beginners.
  • Exponent: mock system design interviews.
  • Martin Kleppmann: academic-level distributed systems lectures.

GitHub Repositories

Books

  • Designing Data-Intensive Applications by Martin Kleppmann: the best technical book on distributed systems and databases. Not beginner-friendly, but worth the effort.
  • System Design Interview by Alex Xu (Volume 1 and 2): the most interview-focused resource. Clear, practical, with worked examples.
  • Clean Architecture by Robert C. Martin: foundational book on software architecture principles.
  • Building Microservices by Sam Newman: the definitive guide to microservices architecture.
  • The Art of Scalability by Martin Abbott and Michael Fisher: engineering and organizational approaches to scaling.
  • Database Internals by Alex Petrov: deep dive into how databases work under the hood.

Free Websites

System Design Interview Questions

Basic Concepts

  1. What is system design? Why is it important for software engineers?
  2. Explain the CAP theorem. What trade-offs does it force?
  3. What is sharding? When would you use it over replication?
  4. What is database replication? How does it differ from sharding?
  5. Explain caching. How do you decide what to cache and for how long?
  6. What are the differences between a monolithic architecture and a microservices architecture? When would you choose each?
  7. What is eventual consistency? Give a real-world example.
  8. What is a load balancer? How does it work? What algorithms does it use?
  9. What are the differences between SQL and NoSQL databases? When would you use each?
  10. What are the common bottlenecks in system design, and how do you mitigate them?
  11. What is a CDN and how does it reduce latency?
  12. What is rate limiting? What algorithms are used to implement it?
  13. What is the difference between latency and throughput?
  14. What is a message queue? When would you use one instead of direct service calls?
  15. What is the difference between synchronous and asynchronous communication?

High-Level System Design

  1. Design a URL shortening service like TinyURL.
  2. Design an e-commerce platform like Amazon.
  3. Design a video streaming platform like YouTube.
  4. Design a social media platform like Twitter or Instagram.
  5. Design a ride-hailing service like Uber.
  6. Design a search engine like Google.
  7. Design a messaging service like WhatsApp.
  8. Design a news feed system like Facebook's.
  9. Design a real-time chat application.
  10. Design a scalable notification system.
  11. Design a file storage and sharing system like Google Drive.
  12. Design an online booking system like MakeMyTrip.
  13. Design a distributed task scheduling system.
  14. Design an API rate limiter.
  15. Design a payment processing system like Razorpay.
  16. Design a system for tracking geolocation data in real time.
  17. Design a logging and monitoring system.
  18. Design a URL analytics service.
  19. Design a subscription-based streaming platform like Netflix.
  20. Design a content recommendation system.
  21. Design a distributed job scheduler like Google Cron.
  22. Design a web crawler.
  23. Design a key-value store like Redis.
  24. Design a distributed cache.
  25. Design a food delivery platform like Swiggy.

Database Design

  1. How would you design the schema for a messaging app like WhatsApp?
  2. How would you design a database for a multi-tenant SaaS system?
  3. How would you handle schema migrations in a live production system?
  4. How would you design a system to store and query time-series data?
  5. How would you manage database partitioning in a high-scale environment?
  6. How would you ensure data integrity across multiple services in a distributed system?
  7. How would you design an audit log system?
  8. When would you use a graph database over a relational database?

Scalability and Performance

  1. How would you design a system to handle 10 million daily active users?
  2. How would you ensure high availability in a distributed system?
  3. How would you handle a massive traffic spike during a flash sale?
  4. How would you scale a relational database when it becomes a bottleneck?
  5. What strategies reduce latency in a globally distributed system?
  6. How do you implement and manage a distributed caching layer?
  7. What are the trade-offs between vertical and horizontal scaling?
  8. How would you design a system for zero-downtime deployments?
  9. How would you handle hotspot keys in a distributed cache?
  10. How would you implement backpressure in a system with variable load?

Real-Time Systems

  1. Design a real-time collaborative document editing system like Google Docs.
  2. Design a stock trading platform.
  3. Design a real-time bidding system for online ads.
  4. Design a system for real-time video conferencing like Google Meet.
  5. Design a system to stream real-time sports scores.
  6. Design a live polling and voting system.
  7. Design a system for real-time event tracking at scale.
  8. Design a multiplayer game backend.

Security and Privacy

  1. How would you design a secure authentication system?
  2. How would you handle data encryption at rest and in transit?
  3. How would you design a system to prevent DDoS attacks?
  4. What is OAuth 2.0 and how would you integrate it into a system?
  5. How would you ensure GDPR compliance in your system design?
  6. How would you design role-based access control (RBAC)?
  7. How would you design a system to detect and prevent fraud?
  8. How would you secure API endpoints from abuse?

Advanced Questions

  1. How would you design a distributed file system like HDFS?
  2. How would you design a system to process streaming data at scale using Kafka?
  3. How would you implement distributed transactions without two-phase commit?
  4. How would you design a feature flag management system?
  5. How would you design a search autocomplete feature?
  6. How would you design a high-frequency trading platform?
  7. How would you implement a distributed consensus algorithm?
  8. How would you design a system for large-scale machine learning model serving?

Trade-offs and Decision Making

  1. How do you decide between consistency and availability in a distributed system?
  2. How would you decide between a monolithic and microservices architecture?
  3. What factors influence your choice of SQL vs NoSQL?
  4. How do you balance cost vs performance in system design?
  5. What trade-offs would you consider when choosing between synchronous and asynchronous processing?
  6. How would you decide between building a feature yourself vs using a managed service?
  7. When would you choose eventual consistency over strong consistency?

Behavioral Questions

  1. Walk me through how you would approach designing a new system from scratch.
  2. Describe a challenging system design problem you worked on and how you approached it.
  3. How do you handle trade-offs when different requirements conflict?
  4. Tell me about a time when your initial design failed to meet requirements. How did you fix it?
  5. How do you explain a complex system design to a non-technical stakeholder?
  6. How do you keep up with new technologies and architecture patterns?
  7. How do you balance speed of development with long-term maintainability?
  8. How do you ensure your design is testable?

The best way to get good at system design is to walk through real systems every week. Read engineering blogs from companies like Netflix, Uber, LinkedIn, and Instagram. They publish detailed writeups about real problems they solved. That hands-on reading is what builds genuine intuition, not just memorizing patterns.

Join our WhatsApp Channel for placement updates, resources, and tips.