Resiliency and Availability Design Patterns for the Cloud
summary
Argues failures are inevitable and shows concrete defenses: deploy across three AZs (one data center can hold ~300,000 servers), use queues that return a job ID so workers process asynchronously, and limit blast radius with redundancy math that turns 99% components into four‑nines by running in parallel. Cites a real outage where default timeouts and retries exhaust connections and take down ~160 servers in 16 minutes. Demonstrates tools and experiments: Eleonora demo, retry storms, Gremlin and Chaos Toolkit, partial failure mode, backoff with jitter, rate limiting and toxiproxy.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:03Failure
- 4:51The most important equation
- 9:50Decoupling
- 17:30Degradation
- 17:59Example
- 18:57Timeouts
- 20:55Defaults
- 22:54Timeout
- 24:54Back Off
- 30:05Request potency
- 32:28Hot zones
- 34:34Shallow pings
- 37:10Rejection
- 38:51Chaos Engineering
- 43:41Tools
- 47:40Gremlin
related talks
32mResiliency and Availability Design Patterns for the Cloud
35mDesign patterns for application resiliency
49mPatterns for resilient, highly available cloud architectures
01h 03mPatterns for Resilient Architecture
51mPatterns for building resilient software systems
37mResilience Design Patterns
16mEngineering Failure-Resilient Systems
55mGoing Resilient