Most outages do not start with something exotic. They start with a retry loop that multiplies a hiccup, a slow dependency that holds every thread hostage, a spike that goes straight to the database, or a dashboard that stays green while customers could not check out. The fixes are old and well documented. They are also missing from a surprising number of production workloads.
This series covers ten of them. I picked each one with the same test: would a Well-Architected Review of a real AWS workload find it missing often enough to matter, and can the post name the AWS services, settings, and limits that build it? A pattern that only makes sense on a whiteboard did not make the cut.
Every post follows the same shape. It opens on the way the failure usually happens, explains the mechanism, shows one diagram, and then gets specific: a table of the AWS services and settings involved, each value checked against AWS documentation and linked to it. Then two sections that matter as much as the mechanism. "When Not to Use It" is honest about cost and complexity, because every one of these patterns has cases where a simpler thing wins. "How We Check for It" names the Well-Architected pillar, question, and best practice, and the evidence we look for in live accounts during a review.
The patterns lean on each other, so the reading order matters. Retries come first because almost every other pattern assumes callers that back off. Queues, load shedding, and caching handle load. Fan-out and read models handle data. Static stability and cells contain failure. Observability comes last because without it you cannot tell whether any of the other nine work.
Read them in order the first time. After that, each post stands on its own.