Card 01/ 07
Matching a Pressure to a Pattern
Read-heavy traffic points to a cache, and global users to a CDN; fifteen pairs like that.
A design heuristic is a rule of thumb that maps a pressure in the requirements to the pattern that usually relieves it: heavy reads that strain the database point to a cache, users spread across the world point to a content delivery network (CDN). Heuristics give a first guess quickly, and every guess must then be checked against the numbers and the requirements.
Where pressures come from. From the requirements and the estimates: a read-to-write ratio of 100 to 1, users on four continents, a sale that brings twenty times normal traffic, a payment that must not be taken twice. Each one is a fact about the product that pushes on the design.
When Users far away, waiting on static files
, chooseWhen The same data read far more often than written, straining the database
, chooseWhen Bursts of writes that the next step cannot take at once
, chooseWhen Requests rising past what the current servers handle
, chooseWhen Load that rises and falls through the day
, chooseWhen Traffic spread across servers that may fail
, chooseWhen A core part whose failure takes everything down
, chooseWhen Data that must survive a machine being lost
, chooseReplication: copies on other machines
When Related records and transactions that must stay correct
, chooseWhen Records whose shape varies, at very large scale
, chooseWhen One relational database past the largest machine
, chooseSharding: splitting the data across databases
When Clients sending far more requests than allowed
, chooseRate limiting at the edge
When Updates both ways, at once
, chooseWhen A transaction that spans several services
, chooseA saga: steps across services, each with an undo
When Clients that retry after a timeout
, chooseAn idempotency key on each request
Read it in pairs. Each heuristic joins two concerns: a kind of traffic and a strain, such as reads and a database bottleneck. One concern alone is not enough: a read-heavy service whose database is idle needs no cache yet.
Patterns owned elsewhere. Replication, sharding, rate limiting, sagas and idempotency keys are named here with a short gloss; the subjects on distributed data and on resilient systems teach how they work.
A heuristic is a first guess. It tells you where to look, not what to build. Check each guess against the estimates, a cache only helps if reads repeat, and against the other requirements, since two heuristics can pull in opposite directions.
So read a brief for its pressures, take the pattern each one points to as a first guess, and keep only the guesses the numbers and requirements support.
- System Design
- Software Architecture
- Performance
← → move through sections and cards