Running a Service That Stays Up
The Helpful Client That Finishes the Job
Last timeMost Outages Are Deployments
A retry is a reasonable response to one failed request and a catastrophic response to a failing service, because it adds load exactly when there is none to spare.
A retry is obviously correct. The request failed, the failure was probably
transient, so try again. Every part of that reasoning is sound for one request
and wrong for a million.
- the requests the users actually made
- the original attempt plus however many retries are permitted
Layers
The multiplier is bad. What makes it dangerous is that it composes.
| layer | attempts per call | requests reaching this l | |
|---|---|---|---|
| browser to gateway | 1 | 3 | 3 |
| gateway to service | 2 | 3 | 9 |
| service to backend | 3 | 3 | 27 |
| backend to database | 4 | 3 | 81 |
Reject early
When the work cannot be done, the cheapest thing to do is say so immediately.
The lesson stops here
3 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents