System design feels overwhelming for one reason: people try to learn it from the top step. Consensus algorithms before load balancers. Distributed transactions before databases. The knowledge is a staircase, not a pile — each step assumes the one below it, and climbing in order turns a scary subject into a sequence of small, obvious ones.
Step 1: Basic — how one system serves users
Load Balancer. One front door that distributes incoming traffic across servers, so no single machine is the ceiling. (NGINX, AWS ELB.)
API Gateway. The single entry point for client requests: routing, authentication, and rate limiting handled in one place instead of inside every service. (Kong, AWS API Gateway.)
Content Delivery Network (CDN). Static assets copied to servers near the user, so a page in Texas does not wait on a disk in Virginia. (Cloudflare, Akamai.)
Database Fundamentals. Where structured data lives — SQL (MySQL, PostgreSQL) and NoSQL (MongoDB) — and how it is queried. Everything above this step exists to protect or feed the database.
Master these four and you can design a system that serves real users. Most internal tools never need more.
Step 2: Intermediate — how a system grows
Caching. Keep hot data in memory so the database stops answering the same question a million times a day. (Redis, Memcached.)
Rate Limiting. Cap requests per user or app, so growth — or abuse — cannot take the system down with enthusiasm.
Database Sharding. Split a dataset across machines, by user ID or region, when one database honestly cannot hold or serve it all.
Replication. Copy data across servers for high availability and disaster recovery — the master–slave setups that keep reads fast and data alive.
This step is where most production systems live. If Step 1 is “working,” Step 2 is “working at ten times the traffic.”
Step 3: Advanced — how systems agree, survive, and stay honest
CAP Theorem. During a network partition, choose consistency or availability. The trade-off that defines distributed systems.
Eventual Consistency. The relaxation of CAP: all nodes will agree eventually, just not instantly. (DynamoDB and most planet-scale systems.)
Distributed Transactions. Keeping an operation atomic across services and databases — coordination protocols like 2PC, and patterns like SAGA when 2PC does not fit.
Consensus Algorithms. How distributed nodes agree on anything — leader, value, state — when some of them are lying dead. (Paxos, Raft; inside etcd and ZooKeeper.)
Message Queues. Decoupling services with asynchronous communication, so a slow consumer never blocks a fast producer. (RabbitMQ, Kafka.)
Service Discovery. In environments where services appear, disappear, and move, something must keep the phone book. (Consul, Eureka.)
System Observability. Monitoring, logging, and tracing — knowing the system’s health from the outside before your users tell you from the inside. (Prometheus, Grafana, Jaeger.)
The bottom line
Basic serves users, intermediate survives growth, advanced survives failure and disagreement. Learn — and interview, and design — in that order, and you will never freeze in a design review again.
Climbing the staircase? The free toolkits collect the reference posters for each step.
