The 7 Quests of Resilient Software Design
summary
Claims seven concrete obstacles to resilient systems: seven quests covering business case (resilience prevents lost revenue, not directly makes money), the reality that distributed systems are hard (non‑deterministic failures, CAP/FLP like limits), the 100% availability trap with availability multiplying down as services grow, broken ops→dev feedback loops, poor functional decomposition, pattern overuse, and knowledge loss. Notes real tooling and practices: Erlang/actor supervisors hit ~99.999779% uptime, Netflix uses circuit breakers, retries, canaries and Simian Army (chaos engineering), and SRE/DevOps style feedback to validate fixes.
AI-written summary · about
chapters (13)
- 0:00Intro
- 2:00Software Design
- 2:32What went wrong
- 3:45Understanding the business case
- 5:15Reduced system availability
- 7:53Distributed systems
- 15:40The 100 available trap
- 18:05The right question
- 18:55Availability
- 25:38Functional Design
- 32:20Caches
- 34:13Patterns
- 40:13Preserve
related talks
22mResilience Is Not Enough
16mSAG Expert Interview #12: The Art of Resilient Software Architecture
41mOnce Upon a Vulnerability: Building Resilience in a Chaotic World
48mUnbreakable by Design: The Secret Tech of Antifragile Software
28mMaking the Impossible Impossible: Improving Reliability by...
38mWhy software developers should build a resilience culture based on chaos engineering
14mAntifragility or taming the hydra
41mFour advanced patterns to improve an application's resilience