Circuit breaker
6 callers meet a dependency that is down and takes about 80ms to say so. One arm asks every time; the other stops after the third failure.
Velocity
Removing latency as an architecture, not a list of tricks: optimistic mutation, cache tiers, stampede protection, deferred tails — each measured against the naive version.
What keeps the fast path fast when a dependency is not. Same two arms, same real modules — this time the dependency is the one that is broken, slow or hanging.
Concurrently — a page about waterfalls should not create one.
Bulkhead
8 calls to a ~100ms dependency are already holding a 4-slot pool when one fast call arrives. One arm shares the pool; the other gives each capability its own compartment.
Deadline propagation
3 sequential calls to a dependency that never answers in time. One arm gives each its own 100ms timeout; the other divides a single 150ms budget between them.
Load shedding and bounded retry belong to the same policy but have no panel here: neither produces a comparison a stopwatch can make honest, and a weak demonstration is worse than none. Both are covered by their unit tests and the docs.
Think this pattern could be better? Tell us how.
Leave feedback