Sign in Get started

Decision guide

Circuit Breaker and Resilience Libraries by Stack

Which resilience library should you use in your stack (or should the mesh do it)?

Side by side

CriterionResilience4j (Java/Kotlin)Polly (.NET)opossum / cockatiel (Node.js)tenacity / pybreaker / stamina (Python)Service mesh (Envoy/Istio/Linkerd)
LanguageJVM.NETNode.jsPythonAny (sidecar/ambient)
Circuit breakerYesYesYesYesOutlier detection / connection limits
Retries with jitterYesYescockatieltenacity/staminaYes (with budgets)
BulkheadYesYes (concurrency limiter)cockatielManual (semaphores)Connection/request limits
App-level fallbacksYesYesYesYesNo
Metrics integrationMicrometerOpenTelemetryEvents/customCustomBuilt-in

When to choose each

Resilience4j (Java/Kotlin)

Modular breakers, retries, bulkheads, rate limiters, time limiters; Spring Boot integration.

Choose when

  • Spring Boot services

Avoid when

  • Non-JVM stacks

Polly (.NET)

Resilience pipelines: retry, breaker, timeout, hedging, rate limiter.

Choose when

  • .NET services (Microsoft.Extensions.Resilience)

Avoid when

  • Non-.NET stacks

opossum / cockatiel (Node.js)

Circuit breakers (opossum) and composable policies (cockatiel).

Choose when

  • Node.js/TypeScript services

Avoid when

  • CPU-bound workers

tenacity / pybreaker / stamina (Python)

Retries with backoff (tenacity, stamina) and breakers (pybreaker, aiobreaker).

Choose when

  • Python services

Avoid when

  • When you need bulkheads/rate limiters in one package

Service mesh (Envoy/Istio/Linkerd)

Timeouts, retries, outlier detection and breaking configured outside the app.

Choose when

  • Polyglot microservices
  • Uniform policies without code changes

Avoid when

  • Fallback logic that needs app context

Verdict

Use your stack's library for app-aware behavior (fallbacks, per-operation policies) and a service mesh for uniform timeouts, retries budgets and outlier detection across many services — but avoid configuring retries in both layers for the same call.

Learn more

Sources