A financial platform's card authorisation path must survive dependency failures, deployments, overloaded downstreams and partial network failures. How should isolation, deadlines, breakers, bulkheads, caching, shedding and fallback combine?

Why they must be designed together

Each mechanism protects against a different failure and several of them interact badly if chosen independently. A retry policy without a deadline extends latency; a circuit breaker without a fallback converts a slow response into an error; a bulkhead without shedding fills its queue and fails anyway.

The coherent strategy is built from the outside in.

The layers

• Admission control at the edge. A hard concurrency limit on the authorisation path, sized so that accepted work can be completed within the deadline. Excess is rejected quickly and explicitly, because a slow rejection causes a client timeout and a retry, which multiplies load.
• A deadline propagated from the inbound request. Card authorisation has a hard external deadline — the network will time out — so every downstream call gets the remaining budget, and a call that cannot complete in time is never started.
• Bulkheads per dependency. Risk scoring, ledger, limits and the network each get their own concurrency allocation, so the slowest cannot consume the pool.
• Circuit breakers tripping on latency as well as errors, because a dependency that is slow but succeeding is invisible to an error-rate breaker and is the more damaging case.
• A local fallback for every non-essential dependency. Cached limits, cached risk scores, deterministic rules — computed locally with no network call, so the fallback does not share the failure.
• Priority shedding, so authorisations survive while reporting, analytics and non-critical webhooks are dropped.

The two rules specific to money

A timeout is not a failure, it is an unknown. An abandoned authorisation may have taken effect, so the breaker opening must produce a state the system knows how to resolve — a reversal, a status query, a pending record — rather than a plain error.

The ledger is never in the fallback path. Risk scoring can degrade to a cached approximation; the record of what was authorised cannot. Anything that must be exact stays exact or the request fails.

The property that ties it together

Every mechanism must be exercised. Thresholds are guesses until fault injection under load shows what the service actually does, and a fallback that has never run in production will not work the first time. A resilience strategy that has not been tested is a design document, and the incident is where the gap between the two becomes visible.