System Design Roadmap
A complete path from system design fundamentals and APIs to scaling, distributed data, reliability and interview-ready architecture design.
Learning outline
Expand a stage, choose a topic and start its Gate Smashers lectures.
01System Design Foundations4 topics · 4 lectures0 / 4
▶What is System Design?0 / 1 lectures
▶HLD vs LLD0 / 1 lectures
▶Client–Server Architecture0 / 1 lectures
▶Core Building Blocks0 / 1 lectures
02APIs & Communication4 topics · 4 lectures0 / 4
▶APIs & Interface Design0 / 1 lectures
▶REST, SOAP, GraphQL, gRPC & WebSockets0 / 1 lectures
▶API vs SDK0 / 1 lectures
▶Message Queues & Event-Driven Systems0 / 1 lectures
03Scaling & Traffic Management6 topics · 7 lectures0 / 7
▶Vertical vs Horizontal Scaling0 / 1 lectures
▶Load Balancing0 / 1 lectures
▶Reverse Proxy & API Gateway0 / 1 lectures
▶Caching0 / 2 lectures
▶Content Delivery Networks0 / 1 lectures
▶Rate Limiting0 / 1 lectures
04Data & Distributed Systems4 topics · 10 lectures0 / 10
▶SQL vs NoSQL0 / 6 lectures
▶Database Replication0 / 1 lectures
▶Partitioning & Sharding0 / 2 lectures
▶CAP Theorem & Consistency Models0 / 1 lectures
05Reliability & Operations2 topics · 5 lectures0 / 5
▶Security in System Design0 / 4 lectures
▶Monolith vs Microservices0 / 1 lectures
06Design Interviews & Revision2 topics · 2 lectures0 / 2
▶System Design Interview Framework0 / 1 lectures
▶Case Study: News Feed0 / 1 lectures
Topics covered in this roadmap
Use this stage-by-stage outline to understand the complete learning path before opening the interactive roadmap.
System Design Foundations
What is System Design?
System design is the process of defining the architecture, components, interfaces and data flow needed to satisfy a system’s requirements. It focuses on how software services work together reliably and efficiently as users, data and traffic grow.
Requirements & Capacity Estimation
A strong system design begins by clarifying functional and non-functional requirements before choosing technologies. Rough capacity estimates help determine expected traffic, storage, bandwidth and scale.
HLD vs LLD
High-Level Design describes the major building blocks of a system and how they communicate, while Low-Level Design describes the internal structure of individual components. Both views are useful, but system design interviews usually begin with HLD.
Client–Server Architecture
Client–server architecture separates request-producing clients from servers that provide data or computation. Modern systems often place multiple layers such as load balancers, gateways, services and databases between the client and stored data.
Core Building Blocks
Large systems are assembled from reusable architectural components such as load balancers, caches, databases, queues and storage services. Understanding each component’s responsibility makes it easier to compose larger designs.
APIs & Communication
APIs & Interface Design
An API defines a contract through which software components communicate. Good API design uses clear resources or operations, predictable inputs and outputs, appropriate status handling and versioning.
REST, SOAP, GraphQL, gRPC & WebSockets
Different communication styles solve different integration problems. REST is resource-oriented, GraphQL allows client-selected data, gRPC provides efficient RPC communication, and WebSockets support long-lived bidirectional connections.
API vs SDK
An API is an interface that lets software communicate with another service or component, while an SDK is a packaged set of tools that helps developers build against a platform. An SDK may wrap one or more APIs and add libraries, models, authentication and utilities.
Synchronous vs Asynchronous Communication
Synchronous communication waits for an immediate response, while asynchronous communication allows work to continue before the final result is available. Distributed systems often combine both styles depending on latency and coupling requirements.
Message Queues & Event-Driven Systems
A message queue stores messages between producers and consumers so components do not need to operate at the same time. Event-driven architectures use events to notify other components that meaningful state changes have occurred.
Scaling & Traffic Management
Vertical vs Horizontal Scaling
Scaling increases a system’s capacity to handle growing load. Vertical scaling adds resources to one machine, while horizontal scaling adds more machines or service instances.
Traffic Distribution
Traffic distribution components route incoming requests across services and servers so that no single instance becomes overloaded. They also provide controlled entry points to backend systems.
Performance Optimisation
Performance optimisation reduces latency and backend workload by serving frequently requested data closer to users or from faster storage layers.
Traffic Protection
Traffic protection keeps services stable during spikes by controlling request rates and slowing producers when downstream systems cannot keep up.
Load Balancing
A load balancer distributes incoming requests across multiple healthy servers so no single instance becomes the only traffic bottleneck. It improves scalability, availability and operational flexibility.
Reverse Proxy & API Gateway
A reverse proxy accepts client requests on behalf of backend servers, while an API gateway provides a broader entry layer for APIs and microservices. Both hide internal topology and can centralize cross-cutting request processing.
Caching
Caching stores frequently or recently accessed data in a faster layer so repeated requests avoid expensive computation or storage reads. Effective caching can dramatically reduce latency and backend load, but introduces freshness and invalidation challenges.
Content Delivery Networks
A Content Delivery Network caches static or cacheable content at geographically distributed edge locations. Serving content near users reduces latency, origin bandwidth and load on central infrastructure.
Rate Limiting
Rate limiting controls how many requests a client or category of traffic may perform within a defined period. It protects services from abuse and overload while enforcing fair resource usage.
Backpressure & Traffic Shaping
Backpressure prevents fast producers from overwhelming slower downstream services by slowing, rejecting or buffering incoming work. It is essential for keeping overloaded distributed systems stable instead of allowing failures to cascade.
Data & Distributed Systems
SQL vs NoSQL
Database selection depends on data relationships, access patterns, consistency needs and scale. Relational databases provide structured schemas and strong transactional support, while NoSQL systems often prioritize flexible models or distributed scaling.
Database Scaling
Database scaling distributes stored data and read or write workload using replication, partitioning and stable key-distribution techniques.
Distributed Data Guarantees
Distributed data guarantees describe how systems balance consistency, availability and correctness when data spans services or machines.
Distributed ID Generation
Distributed systems often need globally unique identifiers without routing every creation request through one database sequence. ID schemes balance uniqueness, ordering, size, coordination and information leakage.
Database Replication
Replication keeps copies of data on multiple nodes to improve availability, read capacity and disaster tolerance. The replication strategy determines how writes propagate and how quickly replicas become consistent.
Partitioning & Sharding
Partitioning divides a dataset into smaller pieces, while sharding distributes those partitions across different machines. Proper partitioning increases capacity but requires careful key selection and rebalancing.
Consistent Hashing
Consistent hashing maps both data keys and servers onto a logical hash ring so adding or removing a server moves only part of the keyspace. It is useful in distributed caches and partitioned systems where membership changes.
CAP Theorem & Consistency Models
CAP describes the trade-off a distributed data system faces when network partitions occur: it cannot simultaneously guarantee both perfect consistency and full availability during the partition. Practical systems choose behavior according to application requirements.
Distributed Transactions
A distributed transaction updates data across multiple independent components while trying to preserve required correctness guarantees. Coordination is difficult because nodes and networks can fail independently.
Reliability & Operations
Reliability & Operations Fundamentals
Reliable systems combine suitable service architecture, fault handling, observability, security and recovery planning so they remain dependable in production.
Service Architecture
Service architecture defines how application capabilities are divided, deployed, discovered and configured across a monolith or multiple services.
Fault Tolerance & High Availability
Fault tolerance allows a system to continue providing acceptable service when individual components fail. High availability is achieved through redundancy, health detection, failover and removal of critical single points of failure.
Logging, Metrics & Tracing
Observability provides evidence about the internal state of a distributed system through logs, metrics and traces. It allows teams to detect incidents, locate bottlenecks and understand request behavior across many services.
Security in System Design
Security must be designed across authentication, authorization, transport, data storage and service boundaries rather than added as a final component. Systems should minimize trust and limit the damage caused by compromised credentials or services.
Monolith vs Microservices
A monolith packages major application capabilities into one deployable unit, while microservices split the system into independently deployable services around business responsibilities. Microservices improve organizational and scaling flexibility but add distributed-system complexity.
Retries, Timeouts & Circuit Breakers
Resilience patterns control how services react when dependencies become slow or unavailable. Proper timeouts, bounded retries and circuit breakers prevent one failing component from consuming resources across the whole system.
Backups & Disaster Recovery
Disaster recovery defines how data and service availability are restored after severe failures. Backup strategy, replication and recovery objectives should match the business impact of downtime and data loss.
Service Discovery & Configuration
Service discovery allows distributed services to locate healthy instances without hard-coded addresses. Dynamic configuration separates deployable application code from environment-specific settings.
Design Interviews & Revision
System Design Interview Framework
A repeatable interview framework keeps the discussion structured and prevents premature technology choices. The process typically moves from requirements and estimates to APIs, data, high-level architecture, bottlenecks and trade-offs.
Case Study: URL Shortener
A URL shortener maps a compact unique key to a longer destination URL and redirects users efficiently. It is a useful introductory design because it combines APIs, key generation, storage, caching and read-heavy scaling.
Case Study: Chat & Notifications
Real-time messaging systems require persistent connections, message routing, durable storage and reliable delivery semantics. Notification systems similarly fan out events to many users or external delivery providers.
Case Study: News Feed
A news-feed system delivers personalized collections of recent content to many users. Its key design challenge is balancing write amplification, read latency, ranking and freshness.
System Design Roadmap Complete
You have completed the System Design roadmap from foundational architecture and APIs through scaling, distributed data, reliability and interview case studies. Revisit the trade-offs and practise explaining complete designs aloud.