Architecture & practice·topic 3 of 10
Risk, blast radius and change
Senior engineers are not more cautious than everyone else; they are more specific about what could go wrong and how far it would spread. These are the terms that turn 'this feels risky' into a claim someone can agree or disagree with.
Read in order · tick what you already know
- 01
one region went down and you found out which of your services quietly lived only in that region.
Failure domain
- 02
the validation was bypassed and the database constraint caught it anyway.
Defence in depth
- 03
you added a null check for a case the caller promised could never happen, and it happened.
Defensive programming
- 04
the permissions service timed out, and the system denied everything rather than letting everything through.
Fail-safe
- 05
the feature added one endpoint, and that endpoint took a file path from the client.
Attack surface
- 06
the automation was doing the wrong thing at 2am and there was no supported way to turn it off.
Escape hatch
- 07
the new code path was on fire and you turned it off with a flag instead of a rollback.
Kill switch
- 08
you shipped it because you knew exactly how you would undo it, not because you were sure.
Reversibility
- 09
you picked the customer-facing URL scheme, and two years of links mean it is never changing.
One-way door
- 10
you argued for a week about a library you could have swapped out in an afternoon.
Two-way door
- 11
the same deploy process guards the marketing site and the payments ledger, and everyone is annoyed.
Risk appetite
- 12
you could list what you did not know about the vendor's API, and that list was the plan.
Known unknowns
- 13
you deleted the odd-looking retry, and a week later found out which flaky vendor it was for.
Chesterton's fence
- 14
you changed the order of a JSON response and a customer's integration broke, and nowhere did you promise an order.
Hyrum's law
- 15
nobody wrote runbooks until an on-call rotation made the same people carry the pager.
Forcing function