Concepts
One idea, one trade-off, one widget with two dials.
The fundamentals the problems are built from. Each is a short write-up and a small interactive model built to make a single trade-off visible — not to look like a diagram.
24 concepts in 5 families
Measuring systems
The vocabulary everything else is written in: what latency and throughput actually are, why a server is full at 70%, what a nine costs, and how to turn 'ten million users' into requests per second.
- Latency and Throughput Try it →How long one request takes, and how many you can serve per second — two different axes that people mix up constantly. Little's law is the one equation that ties them together.The trade-off. Requests in flight = arrival rate × time each one takes. Make anything slower and you need more of everything to hold the same rate.Little's lawconcurrencyresponse time
- Utilisation and Queueing Try it →Why a server is effectively full long before it reaches 100% busy: waiting time curves upward with utilisation, gently at first and then vertically.The trade-off. Every point of utilisation you squeeze out costs more latency than the last one. Running at 70% is a choice to buy latency and burst room with a third of the machine.utilisationheadroomqueueing theory
- Back-of-Envelope Estimation Try it →How to turn 'ten million users' into requests per second, terabytes and gigabits in a minute — the skill every problem in this library opens with.The trade-off. The numbers are wrong by 2× and that is fine. What matters is which one is big, because that decides the design.capacity planningQPSstorage
- Horizontal vs Vertical Scaling Try it →A bigger machine, or more machines. One is simple and has a ceiling; the other has no ceiling and makes everything else harder.The trade-off. Scaling up keeps the system simple until the biggest box is not big enough. Scaling out has no top, but now the load must be spread, state must be shared, and any one box can vanish.scale upscale outredundancy
- Availability and the Nines Try it →What 99.9% actually means in minutes, why chaining services multiplies the downtime, and why two copies divide it.The trade-off. Every dependency in series takes a slice off your availability; every redundant copy in parallel gives one back — at the cost of running it.99.9%SLAredundancy
- Percentiles and Tail Latency Try it →Why the average response time is the wrong number, and why the slowest 1% becomes everyone's problem once a request fans out to many services.The trade-off. Every extra service a request touches raises the chance it meets a slow one. Ten dependencies at a 1% tail means one request in ten is slow.p99percentilesfan-out
- Stateless vs Stateful Try it →A stateless server remembers nothing between requests, so any copy can serve anyone and copies can come and go. State has to live somewhere — the question is where.The trade-off. Keeping state on the server is fast and simple until there is more than one server. Moving it out costs a network hop on every request and buys the ability to scale, deploy and fail without anyone noticing.sessionssticky sessionsshared state
- Idempotency Try it →An operation is idempotent when doing it twice has the same effect as doing it once. It is what makes retries safe — and retries happen whether you planned them or not.The trade-off. Every retry that reaches a server twice is a duplicate unless the server can recognise it. Recognising it costs a key and a lookup on every write; not recognising it costs a double charge.idempotency keyretriesexactly-once
- APIs and Communication Styles Try it →How parts of a system talk: request/response over HTTP, streaming over a held connection, or a message dropped on a queue — and when each is the wrong choice.The trade-off. Polling is simple and wastes requests; pushing is efficient and means holding connections. Synchronous calls are easy to reason about and chain failures; asynchronous ones decouple and complicate.RESTgRPCWebSocket
- CDNs and DNS Try it →The two parts of every request that happen before your servers see it: finding the address, and fetching from a cache near the user instead of from you.The trade-off. An edge cache turns distance and origin load into a hit-rate problem; a DNS TTL turns 'how fast can I move' against 'how many lookups do I pay for'.CDNDNSedge
- SQL vs NoSQL Try it →Choosing a data store is choosing what the database will do for you — joins, transactions, a schema — versus what you will do yourself for scale or flexibility.The trade-off. Normalise and the database keeps every fact once and joins on demand; denormalise and reads are one lookup while every write updates every copy.relationaldocumentkey-value
- SLOs and Error Budgets Try it →How to decide what 'working' means, measure it, and turn the gap between the target and perfection into a budget you can spend on shipping — or must stop and protect.The trade-off. A tighter objective means fewer angry users and less room to ship. The budget is the amount of failure you have agreed is fine; burn it fast and you page someone, burn it slowly and you leave it alone.SLOSLIerror budget