How do circuit breaker implementations differ across Resilience4j (Java), Hystrix (Netflix's now-legacy library), and Polly (.NET) in how you configure and wire a breaker into a call, and why did the industry largely move away from Hystrix's approach?

## The shared core All three libraries implement the same underlying state machine — closed, open, half-open — with equivalent concepts of failure-rate thresholds, wait durations, and fallbacks, so the conceptual model transfers directly between them. What differs is: - the programming model used to wire a breaker around a call, - the surrounding tooling each was built with, - and — in Hystrix's specific case — its default isolation strategy, which is a big part of why it eventually lost favor. ## Hystrix: the command object Hystrix, released by Netflix and popularized heavily through their 2012-era microservices writing, requires each protected operation to be expressed as a `HystrixCommand`: you either subclass `HystrixCommand` and implement a `run()` method (with an optional `getFallback()` override), or use the `@HystrixCommand` annotation on a method with a designated fallback method name. Under the hood, Hystrix defaulted to executing each command on a dedicated thread pool sized per dependency, which gave strong isolation (a slow dependency's threads couldn't spill over and starve threads used by calls to other dependencies) at the cost of real overhead: - extra thread pools per downstream call, - thread-context-switching cost, - and a meaningfully heavier memory/CPU footprint per protected call, especially at high call volume. Hystrix shipped with its own dashboard and a streaming metrics endpoint (Hystrix Dashboard/Turbine) for visualizing breaker state across a fleet, which was genuinely influential and shaped how a generation of engineers thought about operational visibility into resilience. ## Resilience4j: the functional decorator Resilience4j was built later, explicitly as a lighter-weight alternative designed around Java 8's functional style. Rather than requiring a command class, you wrap an existing `Supplier`, `Function`, `Runnable`, or `CompletableFuture` using `CircuitBreaker.decorateSupplier(...)` (or an equivalent decorator method), or apply `@CircuitBreaker` on a Spring-managed method with a designated `fallbackMethod`. Crucially, Resilience4j doesn't mandate thread-pool-per-dependency isolation as a default — the `CircuitBreaker` itself is just a lightweight state-tracking decorator around whatever execution model you're already using — and if you do want bulkhead-style resource isolation, that's a separate, independently composable `Bulkhead` decorator you opt into and stack alongside the `CircuitBreaker`, rather than something baked into the breaker itself. This **composability** — `CircuitBreaker`, `Retry`, `RateLimiter`, `Bulkhead`, `TimeLimiter` all as independent decorators you can layer in any combination — is a deliberate design departure from Hystrix's more monolithic command model, and it maps naturally onto reactive and functional codebases where wrapping a raw method call is far more idiomatic than subclassing a command object. ## Polly: the fluent policy pipeline Polly, the .NET ecosystem's equivalent, follows a similarly composable philosophy: you build a `CircuitBreakerPolicy` (or in modern Polly, a `ResiliencePipeline`) via a fluent configuration API, specifying the failure predicate, thresholds, and duration of break, and then execute your actual call through that policy object — `policy.Execute(() => CallDependency())` — with the option to stack it with Polly's own retry, timeout, and bulkhead-isolation policies in a pipeline. Conceptually it mirrors Resilience4j's decorator-composition approach closely, just idiomatic to .NET's delegate/lambda style rather than Java's functional interfaces. ## Why the industry moved on The reason the industry broadly moved away from Hystrix specifically (Netflix itself announced it was going into maintenance mode around 2018, favoring adaptive concurrency-limit approaches internally for some use cases) comes down to a combination of factors: - the thread-pool-per-dependency model, while offering strong isolation, imposed real overhead that became harder to justify at scale, especially as reactive and non-blocking I/O styles became more common in the Java ecosystem, where Hystrix's thread-per-command model was a poor conceptual fit; - Resilience4j's lighter, more composable, annotation- and functional-friendly design better matched where Spring Boot and reactive Java were heading; - and simply having an actively maintained library mattered once Hystrix's development pace slowed. ## What a migration actually changes A concrete illustration of the practical difference: migrating a Spring Boot service from Hystrix to Resilience4j typically means 1. replacing `@HystrixCommand(fallbackMethod = "...")` on a method with `@CircuitBreaker(name = "paymentService", fallbackMethod = "...")`, 2. removing any bespoke thread-pool-size configuration that Hystrix required per command group, 3. and if resource isolation is still wanted, adding a separate `@Bulkhead` annotation alongside it. The breaker logic itself (thresholds, states, half-open behavior) behaves equivalently, but the surrounding wiring becomes lighter and more explicit about which concerns (breaking vs isolating vs retrying) are handled by which decorator.