Is Resilience4j enough to make fault tolerant software?
summary
Resilience4j implements retries, timeouts, circuit breakers, rate limiters, bulkheads and caching but requires careful tuning: avoid a retry storm by using backoff and conditional retries with idempotency keys (UUIDs); cancel async work with runningFuture true for CompletableFuture; use client-side smart load balancing to avoid repeated retries hitting the same bad pod (the Kubernetes example shows one out of nine retries can still hit the faulty instance); consider delegating to a service mesh like Linkerd, distributed rate limits, load‑leveling queues, canary deployments and chaos testing.
AI-written summary · about
chapters (12)
- 0:00Introduction and motivation
- 2:44What is resilience
- 8:56Handling transient failures
- 19:47Prolonged failures and circuit breakers
- 25:30Rate limiting and dependencies
- 30:06Bulkheading and resource isolation
- 32:41Other resiliency patterns
- 34:52Progressive delivery strategies
- 35:59Chaos testing and disaster recovery
- 37:25Client-side smart load balancing
- 41:38Service mesh alternatives
- 43:05Key takeaways and conclusion
related talks
38mResilience patterns in practice
35mDesign patterns for application resiliency
53mResiliency and Availability Design Patterns for the Cloud
29mThe art of being resilient. How to handle failures gracefully in Distributed Systems.
57mResilience by Design
01h 03mPatterns for Resilient Architecture
55mGoing Resilient
51mPatterns for building resilient software systems