Definition Of Insanity
summary
Argues retries are often correct for ephemeral failures but only if made safe: use timeouts, limits, jitter/backoff and idempotency. Cites a real outage where hard-coded 500 retries without delays caused Redis to be DoSed, recommends externalizing policies (examples: Resilience4j, Polly). Shows two idempotency approaches—client request IDs or server-side MD5 fingerprinting—with tradeoffs (timestamps, validity windows, legacy APIs). Illustrates jitter to avoid retry waves and urges configurable policies to protect overall system health.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:08Distributed systems problems
- 3:39Three challenges
- 6:52Timeouts for stability
- 15:01When to retry
- 24:51Idempotency in retries
- 39:18Definition of insanity
- 40:44Summary
related talks
32mSafe Client Behaviour
34mDistributed Systems - What Can Go Wrong and How to Get It Right
53mResiliency and Availability Design Patterns for the Cloud
44mIs Resilience4j enough to make fault tolerant software?
55mGoing Resilient
57mResilience by Design
42mDesigning for failure
15mBoosting System Resilience: Exponential Backoff