03 / SIMULATE

A dependency fails. What follows?

A slow provider, a full outage, and intermittent errors put different pressures on a caller. Choose a situation, advance the clock, and work through what the circuit breaker can actually change.

3 SITUATIONS · ONE CHECKOUT
Build your own situation

Bring a system you’re working on.

Add components, model processing and database contention, and compare an alternative under the same conditions. Save the whole experiment as a project file.

Open Scenario Studio

Checkout failure experiment

In this situation

The payment provider still accepts requests, but each call holds a worker for three more seconds. Four in five calls eventually fail. Choosing a situation starts a fresh, paused run.

SYSTEM OPERATIONALCHECKOUT / 6 NODES
CHECKOUT SYSTEMBOUNDARY / 01HTTPSREQUESTSYNCSYNCREAD / WRITEClientREQUEST ORIGINAPI GatewayENTRY POINTOrder ServiceSERVICE APayment APIEXTERNAL DEPENDENCYInventoryINTERNAL SERVICEDatabasePERSISTENT STATEFOCUSED VIEW / CHECKOUT PATHvia API gatewaypayment requestClient24 requests / secondOrder ServiceWorkers availablePayment APIHealthy dependencyINVENTORY + DATABASE REMAIN HEALTHY
Request flow HealthySelect a node to inspect
RESPONSE TIME
128ms
ERROR RATE
0.0%
IN-FLIGHT REQUESTS
0
RESPONSES / SECOND
24req/s
Can one slow provider use up your order service’s capacity?

Introduce the failure and watch the next few seconds.

What to notice

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.

Tune the circuit breaker

A lower threshold reacts sooner. A longer cooldown sends fewer probes, but delays the discovery of recovery. Success resets the consecutive-failure count.

THE CIRCUIT LIFECYCLE
CLOSED
OPEN
HALF-OPEN

Introduce a breaker to observe the state machine.

EVENT LOGT + 000s
  1. System ready. Requests are flowing normally.

One step represents one simulated second. Response throughput includes fallbacks; it is not a count of completed payments. The setup link saves your settings, and opens a fresh run.

SYSTEM OPERATIONAL. Circuit not installed. Payment dependency is healthy.

Your experiment in three steps

01 / OBSERVE

Let the pressure build.

Watch the waiting requests. Increase traffic to see capacity fill more quickly.

02 / INTERVENE

Protect the caller.

Introduce a circuit breaker. Enable a fallback. Inspect which failures it can contain.

03 / RECOVER

Give it time to recover.

Restore the dependency. Watch a half-open probe close the circuit and restore normal flow.

Explore the circuit breaker trade-offs