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.
12 concepts in four families
Shaping traffic
What happens to requests before they reach the thing that does the work — spreading them, refusing them, and what refused ones do next.
Load Balancing
Spreading requests across a fleet. The strategies only diverge once requests stop costing the same.
Distributing requests evenly is not the same as distributing work evenly.
round robinleast connectionsweightedTry it →Rate Limiting
Deciding whether this request is allowed through, and what a burst is permitted to do.
Every algorithm trades memory per key against how accurately it handles bursts.
token bucketsliding windowburstsTry it →Retries, Backoff and Jitter
A retry turns a blip into a success — and a thousand retries at once turn a blip into an outage. Backoff spreads them out; jitter stops them lining up.
Every retry adds load to the thing that just failed. Backoff and jitter trade a little extra latency for not making the failure worse.
exponential backoffjitterretry stormsTry it →
Placing data
Where a piece of data lives, how many copies, and how a reader finds it fast. Every choice here trades a cheaper read against a dearer write.
Caching
Keeping a copy closer to the reader. The interesting decision is not where reads go but where writes go.
Every write strategy trades durability against how often you touch the store.
cache-asidewrite-throughwrite-backTry it →Indexing
A sorted copy of one column, so a lookup reads a handful of pages instead of the whole table. Every index makes one read cheaper and every write dearer.
Each index you add speeds up the queries that use it and slows down every insert and update that has to maintain it.
B-treecovering indexwrite amplificationTry it →Bloom Filters
A few bits per item that can say "definitely not here" for billions of items from memory. The price is that "maybe" is sometimes wrong.
Fewer bits per item saves memory and raises the false-positive rate; there is no setting where both are free.
probabilisticmembershipfalse positivesTry it →Sharding & Partitioning
Splitting one dataset across many machines, and what the split costs you.
Range partitioning keeps ordering and invites hot spots; hashing kills both.
rangehashhot spotsTry it →Consistent Hashing
Placing keys on nodes so that adding a node moves a small slice of data instead of nearly all of it.
A hash ring moves 1/N of keys when the cluster changes; hash % N moves almost everything.
partitioningvirtual nodesrebalancingTry it →
Decoupling with messages
Putting a buffer between the part that produces work and the part that does it, so neither has to keep the other's pace.
Agreeing under failure
What several machines can promise about the same value when any of them can crash and any message can be late — and what they cannot.
Replication
Keeping more than one copy of the data, and what a failover costs when the copies disagree.
Synchronous replication charges every write; asynchronous replication charges you once, during a failure.
leader-followerfailoverlagTry it →CAP Theorem
What a distributed system does when the network splits in two — the only moment CAP actually applies.
Partitions are not optional, so the real choice is which promise to break when one happens.
partitionsCPAPTry it →Consensus
Getting several machines to agree on one value — a leader, a log entry, a lock — when any of them can crash and messages can be late. A majority is the whole idea.
A majority quorum survives minority failures and never splits, at the cost of a round trip to most of the cluster on every decision.
Raftleader electionquorumTry it →