System Design
Distributed Systems Architecture & Large-Scale Trade-offs
System Design involves engineering distributed software architectures that scale gracefully to millions of concurrent users while remaining resilient, available, and maintainable.
Track Curriculum
Subtopics & Modules
System Design Fundamentals
Scalability (vertical vs horizontal), availability (99.999%), latency vs throughput, and SLA/SLOs.
Load Balancing & Reverse Proxies
L4 vs L7 load balancers, Round-Robin, Least Connections, Consistent Hashing, and Nginx/HAProxy.
Multi-tier Caching Strategies
CDN edge caching, browser caching, Redis cache patterns, cache invalidation, and LRU algorithms.
Message Queues & Event Streams
Decoupled asynchronous processing, Apache Kafka, RabbitMQ, Pub/Sub, and event-driven architecture.
Microservices & Service Mesh
Distributed systems architecture, 12 principles, design patterns (Saga, CQRS, Outbox), service mesh with Envoy, and production resilience.
API Gateway & Rate Limiting
Token Bucket, Leaky Bucket, Sliding Window Counter algorithms, request routing, and SSL termination.
Distributed Storage & Consensus
Consensus algorithms (Raft, Paxos), DynamoDB quorum writes, vector clocks, and distributed locks.
Interview Questions by Module Topic
Select a module to view its related questions, or explore all modules organized by seniority level
System Design Fundamentals
**Vertical Scaling (Scale Up)** adds more computing resources (RAM, CPU cores, NVMe SSDs) to a single machine. It requires zero application code changes, introduces no network distributed latency, and maintains trivial single-node database ACID transactions. However, it hits hard physical limits (you cannot buy a server with 10,000 CPU cores), suffers from single-point-of-failure (SPOF) downtime during hardware upgrades, and costs grow exponentially at the high end. **Horizontal Scaling (Scale Out)** adds more commodity server nodes behind a load balancer. It offers virtually limitless scaling potential, cost efficiency (commodity hardware), and high availability (if server 1 crashes, traffic shifts to servers 2-10). However, it introduces distributed complexity: stateless API architectures, network serialization latency, distributed database sharding, and eventual consistency trade-offs.
Vertical Scaling (Scale Up):
[ Server: 4 Core / 16GB ] ---> Upgrade ---> [ Monster Server: 128 Core / 2TB RAM ]
Cost: Exponential ($$$$) | Downtime: Required | Failure: 1 Machine dies = Entire site down!
Horizontal Scaling (Scale Out):
Incoming Traffic ---> [ Load Balancer ]
├─── [ Node 1: 4 Core ]
├─── [ Node 2: 4 Core ]
└─── [ Node 3: 4 Core ]
Cost: Linear ($) | Downtime: Zero | Resilience: Any node dies = 0% downtime!🔍 Code Mechanics (Text): Modern production systems scale horizontally at the stateless application tier, while scaling vertically first at the database tier before introducing sharding.