Designing for Failure using AWS: Resilient Systems
summary
Claim: failures are inevitable so design to limit blast radius and recover fast. Concrete techniques include redundancy across availability zones and multiple instances, isolation via separate resource pools and queueed comms, and circuit breaker thresholds with timeouts and exponential backoff and limited retries. Implement graceful degradation for noncritical features, add logging/metrics for diagnosis, and run chaos engineering in production to validate that the built fallbacks actually keep core functionality working and speed recovery.
AI-written summary · about
chapters (10)
- 0:00Introduction to Designing for Failure
- 0:44The Reality of System Failures
- 1:52Why Design for Failure?
- 3:14Core Principles and Techniques
- 3:48Redundancy and Isolation
- 5:00Circuit Breakers and Timeouts
- 6:25Graceful Degradation
- 7:01Monitoring and Observability
- 7:59Shifting the Mindset
- 9:07Conclusion and Final Thoughts
related talks
51mDesigning for Failure: Build Resilient Services
16mResilient by Design: Architectures for Crisis Response & Recovery
57mResilient Cloud Architecture Design Patterns
22mResilience Is Not Enough
40mThe Art of Embracing Failure at Scale
51mWithout Resilience, Nothing Else Matters
34mToward continuous resilience
49mPatterns for resilient, highly available cloud architectures