Skip to main content
System Design

System Design Tutorial with Examples.

System design tutorial with runnable examples: APIs, scaling, reliability, data consistency and end-to-end architecture tradeoffs in production systems.

Also known as High-Level Design.

Architecture at a glance

Click any box to open the lesson that teaches it

System design at a glance

client → CDN → rate limit → load balancer → services → cache → database

System design at a glance A client request passes a CDN cache and a token-bucket rate limiter, then a load balancer spreads it across app instances behind an API gateway and a circuit breaker. Reads go through cache-aside with LRU/LFU eviction before the database, which uses consistent hashing, sharding and replication. Background work moves to events and queues. Distributed locks and leader election coordinate shared state. A bottom strip covers capacity estimation, reliability trade-offs, consistency models, availability, observability and two worked designs. Client CDN edge cache Rate limiter token bucket Load balancer round robin App services many instances Cache reads first Database Service layer API gateway Circuit breaker Caching Cache-aside Eviction Data layer Consistent hash Sharding Replicated Async: events and queues Events vs requests don't block on email Queues absorbs bursts Coordination Distributed lock check-then-delete Leader election split vote Plan and operate Capacity Trade-offs ACID/BASE Consistency Availability Logs/metrics URL design Quorum
How it fits together (7 steps)
  1. A client's request hits the edge first: a CDN cache serves what it can, and a token-bucket rate limiter throttles the rest.
  2. A load balancer spreads what's left across app instances behind an API gateway, and a circuit breaker stops one call from waiting on a service that's already down.
  3. Reads go through cache-aside first, with LRU/LFU eviction deciding what survives in a full cache.
  4. The database layer spreads keys with consistent hashing, splits data with sharding, and survives a primary failure through replication.
  5. Work that doesn't need to block the response moves to events instead of requests, with queues absorbing bursts through backpressure.
  6. Shared state needs coordination: a Redis-based lock serialises access to one resource, and leader election picks one coordinator when several nodes could do the job.
  7. Planning and operating it: capacity estimation turns assumptions into real numbers, retries with backoff trade latency for reliability, ACID vs BASE and consistency under partitions set what a reader can trust, availability arithmetic turns nines into downtime, observability ties logs/metrics/traces into one signal, and a worked URL shortener and quorum consistency walk through two full designs.

Beginner

Start here — no prior experience needed

4 lessons

Intermediate

For developers with core concepts down

4 lessons

Advanced

Production-grade patterns for experienced engineers

3 lessons

Also part of System Design

Taught in other topics. Each link opens the lesson in its home topic.

12 lessons
databases advanced
5 min read

MongoDB's sharding puts data on genuinely separate machines; MySQL's PARTITION BY divides a table by the same kind of range key but keeps every partition on one server. Both engines' own distribution-reporting tools also turn out to report the wrong numbers.

mongodb advanced
5 min read

docker kill the primary node of a real 3-node replica set and time exactly how long the cluster takes to elect a new one from container logs and MongoDB's own timestamps — 9.01 seconds, closely matching the documented default election timeout.

databases advanced
5 min read

A naive read-then-write race loses an update in both PostgreSQL and Redis when neither uses locking — the real difference is that Postgres ships a built-in fix (SELECT ... FOR UPDATE) and a raw key-value GET/SET pair has no equivalent.

interviews advanced
5 min read

CAP without the slogan, why exactly-once delivery is impossible but exactly-once processing is not, and idempotency demonstrated rather than asserted.

event-driven beginner
5 min read

A synchronous order flow fails outright when email is down; an event-driven one records the order and lets each handler fail independently.

cloud-interviews intermediate
5 min read

Why autoscaling reacts too late, Little's law applied to a real queue, and the retry storm that turns a blip into an outage.

redis intermediate
5 min read

Put Redis in front of a slow database and break it on purpose: a stale read, two invalidation races, a 50-request stampede, and the fix for each, measured.

microservices intermediate
5 min read

Retrying a dead dependency forever wastes time on every caller. A circuit breaker as a real closed-open-half-open state machine, tripped by real failures.

microservices intermediate
5 min read

A gateway that calls two backends and combines their responses into one — with a real fallback when one of them is too slow to wait for.

devops intermediate
5 min read

Generate structured logs, aggregate them into metrics, fire an alert off a real threshold breach, and use a trace ID to walk straight back from the alert to the log lines that explain it.

lld intermediate
5 min read

Two ways to shorten a URL — a base62 counter that never collides but leaks a pattern, and a hash that needs real collision handling.

cloud-interviews intermediate
5 min read

What an SLA number actually buys you, RTO versus RPO, why multi-region costs more than twice as much, and the failure modes redundancy does not fix.