The system design path
Lessons are short reads with an exercise and a recap. Labs put several lessons together into one design.
25 modules · 205 lessons · 34 system labs · ~33 hours
Part 1 is open to everyone. A free account opens parts 2 to 4 and saves your progress across devices.
Part 1 · Foundations
01
Thinking in systemsFree
What design actually is, how a design takes shape, and how to weigh one option against another.
- 1.1Decisions, not diagramsWhat you are really producing when you design a system.Read 7m
- 1.2From brief to schemaRequirements, high-level design and low-level design, worked through once on a real example.Read 8m
- 1.3Finding the real requirementsNobody hands you the requirements. You dig them out.Read 6m
- 1.4Weighing trade-offsHow to choose between options that each give something up.Read 5m
- 1.5Lab: Court booking for a sports clubEight courts, 1,200 members, and every evening slot gone minutes after release.Lab 15m
02
One server, one databaseFree
The smallest real architecture: a request path, an API, a schema and the numbers that tell you it is enough.
- 2.1Client, server, databaseThe three parts almost every app starts with, and what each one owns.Read 9m
- 2.2The life of a requestWhat happens between tapping a button and seeing the result.Read 9m
- 2.3Designing the APIResources, verbs and status codes for the food app.Read 8m
- 2.4Pagination, errors and versioningThe small API decisions that are painful to change later.Read 8m
- 2.5SQL or NoSQL?How to pick a database from your data and your queries, not from hype.Read 8m
- 2.6Modelling the dataTables, keys and relationships for restaurants, menus and orders.Read 8m
- 2.7IndexesWhy the same query takes seconds without an index and about a millisecond with one.Read 8m
- 2.8Back-of-the-envelope numbersRough maths that tells you how big the design needs to be.Read 9m
- 2.9Lab: The first version of the food appAPI, schema and numbers for version one, on one server.Lab 18m
03
CachingFree
Answer repeated reads from memory instead of the database, and decide how stale is too stale.
- 3.1Why cache?Most reads ask the same question. Stop asking the database every time.Read 8m
- 3.2Where caches liveBrowser, CDN, server memory and Redis, and what each is good for.Read 9m
- 3.3Cache-asideThe pattern behind most caches: check, miss, load, store.Read 9m
- 3.4Write-through and write-backWhat happens to the cache when the data changes.Read 9m
- 3.5Invalidation and TTLsKeeping the cache from serving yesterday's menu.Read 9m
- 3.6When caches go wrongStampedes, hot keys and lookups for things that do not exist.Read 12m
- 3.7Lab: Cache the menusMake menus fast at dinner time without showing removed dishes.Lab 19m
04
Scaling the app tierFree
Traffic outgrows a single machine. Bigger boxes first, then more of them, and the state problems that follow.
- 4.1Finding the limitLoad testing, and reading CPU, memory and latency like a doctor reads vitals.Read 10m
- 4.2Running a load testA real k6 run, read line by line, and the test setting that hides overload.Read 10m
- 4.3Scaling upThe bigger machine: cheap in effort, and further than most people think.Read 8m
- 4.4Scaling outMany smaller servers, and the new problems they bring.Read 8m
- 4.5Load balancersSpreading requests across servers: algorithms, layers and health checks.Read 12m
- 4.6Stateless serversWhy sessions and uploads break on server two, and where state should live.Read 10m
- 4.7Deploying without downtimeRolling, blue-green and canary releases.Read 10m
- 4.8Dashboards and alertsThe graphs and alarms that tell you at 8pm, not at 9pm, that something broke.Read 9m
- 4.9Lab: Survive the dinner rushTraffic triples at 8pm. Scale the app tier and keep it correct.Lab 18m
05
Scaling the databaseFree
Reads pile up on one primary. Replicas, lag, failover and backups you have actually restored.
- 5.1The database bottleneckSpotting when the database, not the servers, is the limit.Read 10m
- 5.2Connection poolingThe cheapest database fix there is.Read 10m
- 5.3Running PgBouncer and RDS ProxyThe settings, the numbers to watch, and the bugs transaction mode lets in.Read 11m
- 5.4Read replicasCopies that take reads off the primary.Read 10m
- 5.5Replication lag"I placed an order and it vanished." Reading your own writes.Read 10m
- 5.6FailoverThe primary dies at 8:15pm. What happens next?Read 9m
- 5.7Backups and recoveryRPO, RTO, and the backup you never tested.Read 9m
- 5.8Lab: Add replicas safelyScale reads without showing customers stale orders.Lab 19m
06
Real-time updatesFree
Pushing changes to users the moment they happen, from simple polling to WebSockets behind a load balancer.
- 6.1PollingAsking "anything new?" every few seconds, and what it costs.Read 7m
- 6.2Long pollingHold the question open until there is an answer.Read 7m
- 6.3Server-sent eventsA one-way stream from server to client over plain HTTP.Read 7m
- 6.4WebSocketsA two-way connection that stays open.Read 8m
- 6.5Live updates across many serversThe rider is on server 3, the customer on server 7.Read 9m
- 6.6Signing in on a live connectionTokens from native apps, logins that expire mid-connection, and throwing someone off.Read 10m
- 6.7Lab: Live order trackingShow the rider moving on the map for a whole city at dinner time.Lab 19m
07
Background jobsFree
Moving slow work off the request path with queues and workers, and making repeats harmless.
- 7.1Now or later?Deciding what has to happen before the response.Read 8m
- 7.2Queues and workersHand work to a queue, let workers pull it.Read 10m
- 7.3Retries and dead lettersWhat to do with a job that keeps failing.Read 9m
- 7.4Jobs that can run twiceAt-least-once delivery means your job will run twice. Make that harmless.Read 8m
- 7.5Scheduled jobsCron, and making sure only one server runs it.Read 9m
- 7.6Lab: Receipts and payoutsEmail receipts and pay restaurants without blocking checkout.Lab 20m
08
Rate limitingFree
Deciding who gets served when demand exceeds capacity, and enforcing it on every server at once.
- 8.1Why limit?Bots, bugs and one customer who refreshes 50 times a second.Read 8m
- 8.2Fixed and sliding windowsCounting requests per minute, and the edge that lets bursts through.Read 8m
- 8.3Token bucketAllowing short bursts while keeping a steady average.Read 9m
- 8.4Where to limitGateway, server or per feature, and what to send back.Read 9m
- 8.5Limits across many serversOne shared count in Redis, and keeping it fast.Read 10m
- 8.6Rolling out a limitShadow mode, reading what it saw, and switching a limit on without blocking customers.Read 9m
- 8.7Lab: Protect the order APIStop abuse without blocking real customers at dinner time.Lab 21m
09
Growing with your dataFree
Years of history, more cities, more teams. Archive, partition and index before reaching for shards.
- 9.1Data keeps growingThree years and 200 million orders later.Read 9m
- 9.2Archiving old dataMove what nobody reads somewhere cheaper.Read 9m
- 9.3Partitioning a tableSplit one big table into smaller ones, inside one database.Read 8m
- 9.4Changing big tables safelyLocks, lock_timeout, concurrent indexes and backfills on a table that never sleeps.Read 12m
- 9.5A separate search indexWhen "find biryani near me" is too much for the main database.Read 8m
- 9.6ShardingSplitting data across databases, and why you put it off.Read 11m
- 9.7Splitting the appWhen many teams work in one codebase.Read 8m
- 9.8Lab: From one city to tenPlan the growth steps, in order, with numbers.Lab 19m
10
Designing end to endFree
A repeatable method for a blank-page design, and how to defend each choice out loud.
- 10.1A repeatable approachRequirements, numbers, API, data, design, deep dive.Read 9m
- 10.2Explaining your choicesSay what you chose, what you gave up, and why.Read 8m
- 10.3Common mistakesBoxes without reasons, numbers without units, and designing for Google on day one.Read 8m
- 10.4System design interviewsWhat interviewers are actually listening for.Read 8m
- 10.5Lab: A ride-hailing app from a blank pageEverything from Part 1, in one design.Lab 18m
Part 2 · Distributed systems
11
Microservices
When to split a monolith, where to cut, and how to keep a request debuggable across services.
- 11.1Monolith firstWhy most systems should start as one app.Read 8m
- 11.2Drawing boundariesSplit by business capability, and let each service own its data.Read 8m
- 11.3How services talkREST, gRPC and messages, and what each costs.Read 8m
- 11.4API gatewaysOne front door for many services.Read 8m
- 11.5Service discoveryFinding a service whose address keeps changing.Read 7m
- 11.6Tracing a requestLogs, metrics and traces across ten services.Read 9m
- 11.7Lab: Split the food appPick the first service to carve out, and how.Lab 20m
12
Distributed system pitfalls
Lost messages, slow replies, drifting clocks and shared counters: what breaks once work spans machines.
- 12.1The network is unreliableLost, slow and duplicated messages, and why you cannot tell them apart.Read 8m
- 12.2TimeoutsHow long to wait, and what a timeout does and does not tell you.Read 9m
- 12.3Retries and backoffRetrying safely without making an outage worse.Read 8m
- 12.4Idempotency keysMaking a retried request do the work only once.Read 9m
- 12.5Clocks lieWhy two machines disagree about what time it is.Read 9m
- 12.6Counting across machinesLikes, stock and seats when many servers update one number.Read 9m
- 12.7Distributed locksLocks that expire, pauses that last too long, and fencing tokens.Read 13m
- 12.8Cascading failuresOne slow service takes down five. Circuit breakers and bulkheads.Read 9m
13
Replication
Copies of data on many machines: leaders, quorums, conflicts and the consistency each setup really gives you.
- 13.1Why replicate?Availability, read scale and latency, and what each needs.Read 8m
- 13.2Leader and followersOne writer, many readers, and how changes flow.Read 9m
- 13.3Synchronous or asynchronous?Durability against latency, and semi-sync in between.Read 9m
- 13.4Electing a leaderWho takes over, and how to avoid two leaders.Read 10m
- 13.5Consensus: agreeing on a logRaft and Paxos in one lesson, and what they cost.Read 10m
- 13.6Multi-leader replicationWrites in two places at once.Read 9m
- 13.7Leaderless replicationQuorums: write to W, read from R.Read 9m
- 13.8Resolving conflictsLast write wins, merges and CRDTs.Read 9m
- 13.9Consistency modelsLinearizable, causal, eventual, and CAP without the slogans.Read 9m
14
Partitioning
Spreading data across machines by key, and dealing with hot keys, cross-partition queries and moving data.
- 14.1Why partition?When the data or the writes no longer fit on one machine.Read 8m
- 14.2Partitioning by rangeGood for ranges, bad for hot recent data.Read 7m
- 14.3Partitioning by hashEven spread, lost ranges.Read 7m
- 14.4Consistent hashingAdding a machine without moving everything.Read 8m
- 14.5Hot spotsThe celebrity, the big restaurant and other unfair keys.Read 9m
- 14.6Secondary indexesQuerying by something other than the partition key.Read 8m
- 14.7RebalancingMoving data between machines while serving traffic.Read 8m
15
Messaging and event logs
Queues, pub/sub and Kafka-style logs: ordering, consumer groups and what delivery guarantees mean.
- 15.1Queues and pub/subOne worker per message, or every subscriber gets a copy.Read 7m
- 15.2How Kafka worksA log with topics, partitions and offsets.Read 8m
- 15.3Consumer groupsSharing the work, and rebalancing when a consumer dies.Read 8m
- 15.4OrderingOrder within a partition, and choosing the key.Read 8m
- 15.5Delivery guaranteesAt most once, at least once, and what "exactly once" really means.Read 8m
- 15.6The outbox patternSaving to the database and publishing an event, without losing either.Read 8m
- 15.7Kafka, SQS, RabbitMQ or Pulsar?Queues and logs side by side, and what their ordering and exactly-once claims cover.Read 8m
- 15.8Lab: Order eventsNotify the customer, restaurant and rider from one event.Lab 19m
16
Consistency across services
One business action, several databases. Two-phase commit, sagas and compensations, and where each fails.
- 16.1The problemPayment succeeded, the order failed. Now what?Read 7m
- 16.2Two-phase commitEveryone agrees or nobody commits, and why it blocks.Read 8m
- 16.3SagasA chain of local transactions, each with an undo.Read 9m
- 16.4Compensating actionsRefunds, releases and other undos that are not really undos.Read 9m
- 16.5Orchestration or choreography?A central coordinator, or services reacting to events.Read 8m
- 16.6When sagas overlapTwo sagas touching the same data, and semantic locks.Read 9m
- 16.7Try-confirm-cancelReserve first, then confirm or cancel, and surviving a crashed orchestrator.Read 10m
- 16.8Lab: Checkout across servicesOrder, payment and restaurant, with every failure handled.Lab 20m
17
Event-driven data and streaming
Event sourcing, CQRS, change data capture, and processing data as streams or in batches.
- 17.1Event sourcingStore what happened, not just where things ended up.Read 8m
- 17.2CQRSSeparate models for writing and for reading.Read 9m
- 17.3Change data captureTurning database changes into a stream.Read 8m
- 17.4Stream processingComputing results as events arrive.Read 8m
- 17.5Time and windowsEvent time, late events and watermarks.Read 7m
- 17.6Batch processingLarge jobs over all the data, and when they beat streams.Read 8m
- 17.7Data skewOne key gets most of the work: broadcast joins, salting and two-phase aggregation.Read 8m
- 17.8Lab: Live restaurant dashboardOrders per minute and prep times, updated live.Lab 18m
18
High availability and multi-region
Uptime targets and error budgets, removing single points of failure, and serving users across regions.
- 18.1SLIs, SLOs and ninesPicking an uptime target and an error budget.Read 8m
- 18.2Removing single points of failureRedundancy at every layer, and what it costs.Read 8m
- 18.3Degrading gracefullyRecommendations down, ordering still works.Read 7m
- 18.4Disaster recoveryWhen a whole data centre goes away.Read 9m
- 18.5Running in many regionsActive-passive, active-active, and where the data lives.Read 8m
- 18.6Routing users globallyGeoDNS, anycast and CDNs.Read 9m
- 18.7Cells and shuffle shardingLimiting how much of the business one failure can reach.Read 8m
Part 3 · Algorithms and internals
19
Algorithms behind big systems
Clocks, hashing, sketches, consensus and storage structures, traced by hand.
- 19.1Lamport clocksOrdering events without trusting wall clocks.Read 8m
- 19.2Vector clocksTelling "happened before" from "happened at the same time".Read 8m
- 19.3The consistent hash ringVirtual nodes and how much data moves.Read 8m
- 19.4Rendezvous hashingHighest random weight, a simpler alternative to the ring.Read 7m
- 19.5Bloom filters"Definitely not" or "maybe", in very little memory.Read 8m
- 19.6Count-min sketchApproximate counts for millions of keys.Read 8m
- 19.7HyperLogLogCounting unique visitors in 12 KB.Read 9m
- 19.8Percentile sketchesp99 latency across a fleet in a few kilobytes, and why you can't average percentiles.Read 11m
- 19.9Top-K heavy hittersTrending items from an endless stream.Read 9m
- 19.10Merkle treesFinding which data differs between two replicas.Read 8m
- 19.11Gossip protocolsSpreading news through a cluster like a rumour.Read 8m
- 19.12Failure detectionHeartbeats and the phi accrual detector.Read 9m
- 19.13Raft: leader electionTerms, votes and randomised timeouts.Read 9m
- 19.14Raft: log replicationHow a majority commits an entry.Read 9m
- 19.15Write-ahead logsHow databases survive a crash mid-write.Read 9m
- 19.16B-treesThe index inside almost every relational database.Read 9m
- 19.17LSM treesFast writes with memtables, SSTables and compaction.Read 10m
- 19.18Geohashes and quadtreesFinding everything near a point.Read 10m
- 19.19Unique IDs at scaleUUIDs, Snowflake IDs and ticket servers.Read 9m
- 19.20CRDTsData types that merge without conflicts.Read 10m
- 19.21PaxosThe original consensus algorithm, and how it relates to Raft.Read 10m
- 19.22Tries and FSTsPrefix search for autocomplete and dictionaries, without a database.Read 9m
Part 4 · Going deeper
20
Databases in depth
What a single database promises inside: transactions, isolation, locking, and the other kinds of stores.
- 20.1ACID, honestlyWhat atomicity, consistency, isolation and durability actually guarantee.Read 9m
- 20.2Isolation levelsRead committed, snapshot, serializable, and the anomalies each allows.Read 10m
- 20.3MVCCHow readers and writers stop blocking each other.Read 9m
- 20.4Pessimistic and optimistic lockingSELECT FOR UPDATE, version columns, and choosing between them.Read 9m
- 20.5Serializable or linearizable?Two "strongest" guarantees, the different questions they answer, and strict serializability.Read 7m
- 20.6How a query runsPlanners, EXPLAIN, and why the database ignored your index.Read 13m
- 20.7From memory to diskBuffer pools, the OS page cache, and what fsync really promises.Read 10m
- 20.8Database proxiesPgBouncer, ProxySQL and what sits between the app and the database.Read 9m
- 20.9Columnar, wide-column and graph storesWhen rows in tables are the wrong shape for the data.Read 9m
- 20.10Inside a columnar fileParquet row groups, encodings, and skipping data you never read.Read 8m
21
Key technologies
The building blocks that show up in every design: what they are good at, how they work inside, and where they hurt.
- 21.1RedisData structures, persistence, replication and cluster mode.Read 9m
- 21.2ElasticsearchInverted indexes, shards, relevance, and keeping it in sync.Read 8m
- 21.3Object storage (S3)Buckets, presigned URLs, multipart uploads and durability.Read 8m
- 21.4CDNsEdges, origins, push and pull, and cache keys.Read 8m
- 21.5ZooKeeper and etcdLeases, watches, config and leader election as a service.Read 8m
- 21.6CassandraWide rows, tunable consistency and designing tables per query.Read 8m
- 21.7DynamoDBPartition keys, sort keys, GSIs and capacity.Read 9m
22
Networking and API essentials
What happens on the wire, and how services agree on what they send.
- 22.1DNSFrom a name to an address, and how caching makes it fast.Read 10m
- 22.2TCP, UDP and QUICReliable streams, fire-and-forget packets, and the newer middle ground.Read 9m
- 22.3HTTP/1.1, HTTP/2 and HTTP/3Connections, multiplexing and head-of-line blocking.Read 8m
- 22.4TLSHow HTTPS keeps traffic private, and what the handshake costs.Read 9m
- 22.5REST, gRPC or GraphQL?Three API styles and when each one fits.Read 8m
- 22.6WebhooksCalling your customers back, safely and reliably.Read 9m
- 22.7Encoding and schema evolutionJSON, Protobuf, Avro, and changing a format without breaking anyone.Read 9m
23
Security and operations
Keeping the system safe, watching it run, and keeping it standing under stress.
- 23.1AuthenticationSessions, tokens and JWTs, and where each goes wrong.Read 9m
- 23.2Authorization and OAuthRoles, permissions, and letting another app act for a user.Read 8m
- 23.3Secrets and encryptionEncryption in transit and at rest, and where keys live.Read 10m
- 23.4Deleting data everywhereErasure across replicas, caches, logs, lakes and backups, crypto-shredding and data residency.Read 9m
- 23.5Metrics, logs and alertsKnowing something is wrong before your customers tell you.Read 7m
- 23.6Load shedding and backpressureSaying no early so you can keep saying yes.Read 8m
- 23.7Capacity planning and costHow much hardware you need, and what it costs.Read 9m
- 23.8Incidents and postmortemsWhat to do when it breaks anyway.Read 9m
- 23.9Testing distributed systemsTLA+, deterministic simulation, Jepsen and fault injection.Read 9m
24
Designing AI systems
System design for AI features: retrieval, agents and MCP, prompt injection, caching, evals, fine-tuning, and the feature pipelines behind classical models.
- 24.1LLMs for system designersTokens, context windows, latency and why outputs vary.Read 9m
- 24.2Structured output and tool useGetting JSON back, and letting the model call your APIs.Read 9m
- 24.3Retrieval-augmented generationChunking, embeddings and vector search over your own documents.Read 10m
- 24.4Hybrid search and re-rankingCombining keyword and vector search, then re-ranking.Read 9m
- 24.5Agent loopsPlan, act, observe: and checkpoints, timeouts and humans in the loop.Read 9m
- 24.6MCP: tools as a serviceThe Model Context Protocol: servers, transports, OAuth sign-in, and when plain tool calls are enough.Read 12m
- 24.7Prompt injection defencesWhy filters fail, the lethal trifecta, and designs that stay safe when the model is fooled.Read 11m
- 24.8Caching and costPrompt caching, semantic caching and model routing.Read 10m
- 24.9EvalsTesting something that answers differently every time.Read 9m
- 24.10Prompting, RAG or fine-tuning?Which lever fixes which problem, and the numbers that decide when fine-tuning pays.Read 8m
- 24.11Feature stores and training-serving skewClassical ML in production: computing features twice, leakage, and logging what you served.Read 8m
- 24.12Lab: Ask questions over 10 million documentsDesign a RAG system end to end.Lab 21m
25
Real-world systems
The systems behind the ideas in this course, as their builders described them: what problem each solved, and what it gave up.
- 25.1GFS: one master, many chunksHow Google stored huge files on cheap machines that fail every day.Read 13m
- 25.2MapReduce: batch jobs for everyoneMap, shuffle, reduce, and re-running work when a machine dies.Read 12m
- 25.3Bigtable: a sorted map across thousands of machinesTablets, an LSM storage engine, and a lock service holding it together.Read 13m
- 25.4Chubby: a lock service built on PaxosCoarse-grained locks, leases and why Google wanted a service, not a library.Read 15m
- 25.5Spanner: transactions across the planetTrueTime, commit wait, and external consistency at global scale.Read 14m