Start Here
Design Desk teaches system design through mechanisms, failure modes, trade-offs, and real systems, not slides. Pick where you actually are below.
New to system design
Start with Core Concepts, in this order. Everything else in Foundations builds on these four.
Availability
The percentage that describes whether a system responds, not whether the response is right.
Scalability
The ability to handle more load by adding resources, and why which resource you add decides whether that actually works.
Latency vs Throughput
Two different axes that don't move together, and why optimizing one without checking the other ships a system that looks fast and falls over under load.
CAP Theorem
Why a network partition forces a choice between a wrong answer and no answer, and why that choice is usually made per operation, not once for the whole system.
I already know the basics
The rest of Foundations, grouped by area.
Storage & Data
Databases (SQL vs NoSQL)
Why a rigid schema and joins buy correctness guarantees that a flexible, schemaless store trades away for write scale, and why most real systems end up using both.
Caching
The fastest way to answer a read is to not ask the database at all, and the hard part was never storing the copy, it's knowing when to throw it away.
Database Sharding
Splitting one database that's run out of room to grow into many smaller ones, and why the one decision that matters is the key you split it on.
Database Indexes
Why a query that's instant at 10,000 rows becomes a full table scan at 10 million, and why every index that fixes it has a cost on every write.
Database Replication
Copying a database onto more than one machine fixes a read ceiling and a single point of failure at once, but only after you decide how far behind a copy is allowed to be.
Networking & Delivery
Load Balancers
The stateless app tier was never the bottleneck. Something still has to decide, request by request, which of ten identical machines gets it.
CDN
Server processing time was never the bottleneck for a user on the other side of the planet, the trip there and back was, and the hard part isn't caching, it's knowing when to stop trusting the cached copy.
Message Queues
Making a caller wait on a step they don't actually need the answer to, and why the fix trades that wait for a guarantee that a message might show up twice.
Rate Limiting
Capping how much of an API one client can take, and why the naive way to count requests lets exactly double the limit through at the worst possible moment.
API Gateway
Consolidating auth, rate limiting, and logging into one place instead of five, at the cost of a new hop everything has to survive.
Architecture Patterns
Microservices Architecture
Splitting one deployable into many trades one class of problem, deploy coupling, for another: network calls where function calls used to be, and who owns which table now that one database is several.
Event-Driven Architecture
Decoupling who reacts to something happening from the service where it happened, and why that same decoupling makes 'what actually happened, in order' the hardest question to answer when something breaks.
CQRS
One schema trying to be good at writes and good at reads at the same time, and why splitting them into two models means the read side is never perfectly caught up.
Circuit Breaker
A downstream dependency going slow can take down a perfectly healthy caller too, and the fix is knowing when to stop calling entirely, not just when to retry.
Monolith vs Microservices
The mechanics of splitting a system are the easy part. The actual decision is about your org, not your traffic.
Security
Authentication vs Authorization
Checking that someone is logged in and checking that they're allowed to see this specific thing are two different questions, and a codebase that only ever asks the first one has a very quiet bug in it.
JWT & Sessions
Two ways to answer "who's calling" on every request, and why the one that avoids a database lookup can't be undone before it expires.
OAuth 2.0 & OpenID Connect
Letting a third-party app act on your behalf without handing it your password, and why the protocol for that got mistaken for a login system so often that it grew one on top.
Encryption & TLS
HTTPS protects a token while it's traveling between two points. It has nothing to say about what happens to that same data sitting in a database, a log file, or a backup.
Password Hashing
A database breach that hands over plaintext passwords compromises every user instantly. The fix isn't just hashing them, it's hashing them with something deliberately slow.
Reliability
Idempotency Keys
A client-supplied key that turns 'did this already happen' from a guess into a lookup.
Outbox Pattern
A database commit and a message publish can't be one atomic operation across two systems, and the outbox pattern is how you get the guarantee anyway, by only ever making one of them atomic and letting the other catch up.
Observability & SRE
Metrics, Logs & Traces
Three signals that each answer a different question, and why having all three doesn't mean you can answer which of six services actually caused it.
SLIs, SLOs & Error Budgets
An SLO is a deliberate choice of how much unreliability is acceptable, not a target to always beat, and spending the budget is supposed to change what the team does next, not just how the team feels about last month.
Distributed Tracing
A trace id generated once at the edge and carried forward on every hop, and why one service that quietly drops it doesn't throw an error, it just leaves a gap that looks like the request vanished.
Alerting & On-Call
Alerting on causes instead of symptoms produces exactly the kind of flood that buries the one page that actually mattered.
Health Checks & Readiness Probes
Alive and ready are two different questions, and answering both with one check gets a warming-up instance traffic it can't handle, or a momentarily busy one killed for no reason.
Disaster Recovery
"We have backups" answers neither of the two questions that matter: how much data you'd lose, and how long you'd be down while restoring.
Chaos Engineering
A circuit breaker that's never tripped and one that works look identical on a dashboard, until a real outage proves only one of them was ever true.
Or, if you already know what you want
- I want to practice
Every quick-check question from Foundations and the case studies, in one place, each linking back to where it's explained.
- I want to study complete systems
Full case-study write-ups, each with a working diagram, grouped by track.
- I want to understand trade-offs
Every trade-off table from Foundations and the case studies, in one place.
- I learn from real production problems
Writing: incidents from production, written up after the fact, what broke, why, and what changed.