I Designed My AWS Architecture Around Failure First

I stopped asking what AWS services I needed and started asking what could go wrong.

When I first designed AWS systems, I started with the happy path:

Request
  ↓
Backend
  ↓
Database
  ↓
Response

Then I picked services — API Gateway, Lambda, RDS, S3, SQS, CloudWatch, maybe Redis.

The architecture looked reasonable, but also familiar.

Then I learned to ask better questions:

Database unavailable?
Dependency takes 30 seconds?
Message delivered twice?
Region fails?
Queue grows faster than workers?
Deployment breaks?
System works but nobody understands it?

Those questions changed how I design AWS systems.

Instead of starting with services, I started with failure scenarios.

And surprisingly, that usually made the architecture simpler.

1. The Happy Path Was Hiding Most of My Architecture Problems

The first version of an architecture usually looks something like this:

Client
  |
  v
API
  |
  v
Database