Patterns for building resilient software systems
summary
Explains concrete resiliency patterns and what to build: use cell architecture and multi‑AZ regions (three AZs, thousands of isolated cells) to limit blast radius; implement shuffle sharding (can be done via DNS) so noisy tenants affect only ~3–4% of customers instead of everyone; prefer queues and read/write separation for decoupling; pass a deadline timeout from client, use exponential backoff + jitter for retries, and make retries idempotent; use auto scaling for fast self‑healing, circuit breakers with fallbacks, and regular chaos engineering (game days) to validate behavior.
AI-written summary · about
chapters (17)
- 0:00Intro
- 1:06What is resiliency
- 4:25Regional patterns
- 5:11How regions work
- 8:22Patterns for building resilient systems
- 12:35Workload isolation
- 14:41Cascading failure
- 16:33Shuffle starting
- 20:18Autoscaling
- 22:37Synchronicity
- 30:05Timeouts
- 31:02Backend timeouts
- 36:04Retry
- 37:29Health
- 42:27Database resiliency
- 46:56Chaos engineering
- 49:30Steady states
related talks
01h 03mPatterns for Resilient Architecture
35mDesign patterns for application resiliency
32mResiliency and Availability Design Patterns for the Cloud
37mResilience Design Patterns
53mResiliency and Availability Design Patterns for the Cloud
49mPatterns for resilient, highly available cloud architectures
55mGoing Resilient
44mArchitectural patterns of resilient distributed systems