A diagram is only
the beginning.
The boxes look reasonable. Then a dependency slows down, requests start waiting, and the interesting questions begin.
Let’s try it01A checkout with a weak link.
Start with the payment provider. The rest follows.
Introduce the failure and watch the next few seconds.
The checkout path has capacity to spare.
Start with a healthy provider and 24 incoming requests per second. The readouts show the baseline.
Why this happens
Healthy calls finish in the same simulated second they arrive, leaving workers available for the next requests.
Try this next
Introduce failure, then follow the payment call and the order service’s in-flight requests.
The trade-off
A healthy baseline tells you little about how the caller behaves when a dependency slows down or fails.
SYSTEM OPERATIONAL. Circuit not installed. Payment dependency is healthy.
Only the payment dependency is under test. Inventory and storage stay healthy, so you can see where the failure stops.
Build your own scenarioThree providers. How long does your caller wait?
Compare synchronous calls and queued work. Try timeouts, retries, and a provider that stops answering.
Start with something
that could go wrong.
A pattern makes more sense when you have a reason to use it. These five experiments begin with a problem you might actually meet, and each one decides something at a different level — how failure is contained, how work moves, how a system is changed while it runs.
Browse the collectionWhat if a dependency stops keeping up?
Can you undo half a transaction?
The write succeeded. Why is the screen stale?
How do you replace a system people still use?
Does accepting the work mean it is done?
03The same system, a different question.
There is no best architecture, only ones that fit a given set of goals and constraints better than the alternatives. Change the constraints and the answer is allowed to change.
Model a system you actually work on.
Draw the components and connections, give them processing times and capacity, then put the whole thing under load. Create an alternative design and compare both under the same traffic and the same failure.
Would another architecture
make this easier?
Put two approaches beside each other. Change a constraint and see where the trade-offs move.
Make a comparison Work through a decisionWhat fits the system
you’re actually building?
Bring your team size, workload, and priorities. Get a reasoned starting point you can inspect and challenge.
Try your own constraints