How to learn system design
System design is the part of engineering with no correct answer, only defensible ones. That is what makes it hard to study and easy to fake. You can memorise a diagram of how a URL shortener works and still have no idea what to do when your own service starts timing out at 3am.
The people who are genuinely good at it are not recalling architectures. They are running a small set of numbers in their head, noticing which constraint binds first, and saying out loud why they would accept one failure mode over another. That is a learnable skill, and it is learnable faster than most people expect, but only in a particular order.
01 / What system design actually is
Every system design question is the same question wearing different clothes: given more load than one machine can handle, where do you put the work, where do you put the data, and what do you give up. Everything else is detail.
The three things you give up are almost always the same. Consistency, so a read might be stale. Availability, so a request might fail rather than lie. Or money, so you buy your way out with more machines and more cache. A good answer names which one it is spending and why that is the right trade for this product.
This is why memorising architectures does not work. The architecture is the conclusion. Without the argument that produced it, you cannot adapt it when the constraints change, and the constraints always change.
02 / The order that works
20 days of this path, in sequence
The production phase comes first on purpose. Retries, timeouts, idempotency and observability are not adjacent topics. They are the vocabulary the design phase argues in, and skipping them is why so many people can draw a system but not defend one.
- 47Testing: what's worth testing, and what isn't
- 48Integration and end-to-end tests
- 49Logging that helps you at 3am
- 50Docker, and why containers exist at all
- 51CI, CD, and deployment pipelines
- 52Environments, configuration, and secrets management
- 53Observability: logs, metrics, and traces
- 54Latency, throughput, and profiling intuition
- 55Timeouts, retries, backoff, and idempotency
- 56Write a production readiness checklist
- 57How to approach a system design question
- 58Estimating traffic, storage, and capacity
- 59Scaling up, scaling out, and load balancing
- 60Caching: hits, misses, invalidation, and Redis
- 61Replication, partitioning, and sharding
- 62Consistency, availability, and CAP intuition
- 63Queues, workers, and event-driven architecture
- 64WebSockets, polling, and streaming
- 65Monoliths, modular monoliths, and microservices
- 66Design one system end to end
Every one of those days is free to read in full. See all 90.
03 / Where people go wrong
- 01
Starting with the diagram instead of the numbers
Boxes and arrows are the last step, not the first. Before anything is drawn you should know roughly how many requests per second, how much data per day, and how much of it is reads. Those three numbers eliminate most of the design space immediately, and getting them wrong by an order of magnitude means every box after that is decoration.
- 02
Memorising architectures instead of the reasoning
Knowing that Twitter fans out on write is trivia. Knowing why fanout on write beats fanout on read when reads outnumber writes by a thousand to one, and what breaks when a celebrity has forty million followers, is the actual skill. The second one generates the first. It does not work the other way round.
- 03
Skipping caching and going straight to sharding
Sharding is the interesting answer, so people reach for it first. It is almost always the wrong first answer. A cache in front of a single database buys an order of magnitude for a fraction of the complexity, and the engineer who reaches for sharding immediately is telling you they have never operated a sharded system.
- 04
Treating it as interview trivia
System design questions feel like a rite of passage, so people study them as a test to pass rather than a way of thinking. The tell is someone who can design a chat app fluently and then freezes when asked what they would do if their own deploy doubled p99 latency. Study it as the thing you will actually do, and the interview stops being a separate skill.
04 / How long it takes
Twenty days at two to three hours, which is the span above. That is enough to estimate capacity out loud, reason about caching and sharding without reciting, argue consistency tradeoffs, and design a handful of real systems end to end.
It is not enough to have operated any of it at scale, and nothing that fits in twenty days would be. What it does is close the gap between not knowing where to start and being able to hold the conversation, which is the gap that actually stops people.
05 / Common questions
- Can I learn system design without a backend job?
- Yes, with one caveat. The reasoning is entirely learnable from outside: estimation, tradeoffs, caching, replication, consistency. What you cannot get without operating something is the instinct for which failures are common, and the production phase before the design phase exists specifically to substitute for that as far as anything can.
- Do I need to memorise famous architectures?
- No, and doing it early actively hurts. Work through enough designs from first principles and the famous ones become obvious, because they are what the reasoning produces. Memorise them first and you will apply them to problems they do not fit.
- Is twenty days really enough for system design?
- For the reasoning, yes. Twenty days at two to three hours is roughly sixty hours of focused work, which is more than most university modules spend on the topic. What it does not buy is the operational scar tissue that comes from being paged, and no course buys that.
The whole path is free and public.
Read the roadmap, open any day, and decide for yourself. Signing in is only so ninety days of progress survives a cleared browser.