Architecture Failure Simulator

Kill components and watch what happens to real user flows: what breaks, what still works, whether a retry happens, whether data is lost, and whether the user sees an error. Toggle mitigations to see which one actually buys resilience. This is failure-domain thinking made visible.

Kill components, see what breaks
Twelve components, eight user flows, seven mitigations. Every outcome is computed by a deterministic rule set: kill something, see which flows fail, retry, lose data or show the user an error — then switch on the mitigation that would have saved you.
ClientCDNLoad balancerAPI servers ×3Redis cacheRead replicaQueueSearch enginePayment providerWorkersPrimary DBEmail provider
Kill
Mitigations
flows working
5
degraded
0
failing
3
single points of failure
8 · checkout: CDN, Load balancer, All API servers, Primary DB, Payment provider
FlowStatusRetryDataUser sees errorWhy
Browse catalog
CDN → LB → API → Redis (miss: Primary DB)
failsintacterrorRedis is down and the read path assumes the cache is there: connection refused becomes a 500. The database was healthy the whole time.
Search
CDN → LB → API → Search engine
worksintactnoSearch engine answers directly.
Login
CDN → LB → API → Primary DB (user) + Redis (session)
failsdata losterrorSessions live in Redis. Nobody can log in, and everyone who was logged in is logged out — the cache was quietly a database.
Add to cart
CDN → LB → API → Redis (cart hash)
failsdata losterrorCarts are stored only in Redis without persistence: existing carts are gone and new items cannot be added. Cache-aside does not help data that has no other home.
Checkout (charge)
CDN → LB → API → Payment provider → Primary DB → Queue
worksintactnoOrder committed, card charged, OrderCreated published.
Order confirmation email
Queue → Workers → Email provider → Primary DB
worksintactnoQueue → worker → provider, order marked notified.
View order history
CDN → LB → API → Primary DB
worksintactnoRead from the primary; the replica is a standby.
Static assets
CDN edge (origin only on a cache miss)
worksintactnoServed from the CDN edge.
Redis cache down: 3 flows failing, 0 degraded. A cache that also holds sessions and carts is not a cache — it is a database with no durability.
Most valuable next mitigation: “cache-aside falls back to DB on Redis loss” — it would improve 1 step in the table right now.
Preset

How to read it

A failure domain is the set of things that stop working when one thing dies.

Works / degraded / fails
A flow is degraded when it still completes but slower, staler, or with a feature missing — that is the goal of most mitigations. A flow fails when the user cannot complete it.
Data lost vs inconsistent
Losing a committed order is data loss. Committing the order but losing the event that tells the email service is inconsistency — repairable, but only if you notice. The outbox pattern turns the second into “delayed”.
Single points of failure
Computed by killing each component alone. The list tells you where redundancy or a fallback pays for itself first — usually the primary database and whatever sits in front of it.