Netflix: From Hystrix to Adaptive Concurrency Limits
also called Hystrix, Concurrency Limits
Netflix's widely-copied circuit breaker library was retired in favour of limits that derive themselves from observed latency, because static thresholds go stale.
The problem
Hystrix gave a generation of engineers their mental model of the circuit breaker: bulkheaded thread pools per dependency, a failure-rate threshold, an open state, a half-open probe. It was enormously influential and Netflix placed it in maintenance mode in 2018.
The reason is instructive. Every Hystrix configuration is a set of static numbers — pool size, timeout, error threshold, sleep window — and every one of them is a guess that decays. Traffic grows, the dependency gets faster or slower, an instance type changes, and the thresholds that were correct last quarter are now either tripping on normal variance or failing to trip when it matters. Across hundreds of services and thousands of dependency pairs, nobody can keep them current.
What they did
Netflix moved towards adaptive concurrency limits, taking the idea from TCP congestion control. Rather than configuring how many concurrent requests are allowed, the system measures latency continuously and infers the limit: when latency starts rising above the observed minimum, the system is queueing, so the limit is reduced. When latency is flat, the limit can grow.
This is Little's Law used as a control loop. The system finds its own capacity, and it re-finds it every time conditions change.
The trade-off
Adaptive limits are harder to reason about and to explain during an incident — "why did we shed that request" has an answer derived from a moving measurement rather than from a configured number. They also need a clean latency signal; a dependency with naturally bimodal latency confuses the control loop.
Static breakers remain easier to understand, and for a small estate with a handful of dependencies, tuning them by hand is entirely feasible.
The transferable lesson
The cost of a resilience mechanism is its ongoing tuning, not its implementation. Any control that requires a human to keep a number correct across hundreds of services will drift out of correctness, and a drifted circuit breaker is worse than none because it trips during traffic spikes and causes the outage it exists to prevent.
Before adopting a pattern, ask who maintains its configuration in two years.