Going Resilient
summary
Outlines concrete principles: model failures as normal, build crash-only components that restart in isolation, and protect critical data in a minimal error kernel. Recommends asynchronous patterns—asynchronous messaging and queues—with supervision, retries, caching, circuit breakers and throttling to avoid cascade. Advises using infrastructure that already offers redundancy and service discovery (Kubernetes/etcd, Netflix-style tooling, Vert.x) and running chaos-style tests (kill -9, drop/duplicate/reorder messages) to verify that automatic restart and failover actually work.
AI-written summary · about
chapters (20)
- 0:00Introduction to resilience
- 1:54Speaker background
- 2:16Defining resilience
- 6:32Why systems fail
- 8:21Complex systems and failure
- 14:50Embrace failures in design
- 16:37Complex systems run degraded
- 19:48Failure management is design
- 21:13Crash-only design pattern
- 27:46Prevent cascading failures
- 29:36Supervision mechanisms
- 30:37Minimal error kernel pattern
- 33:04Handling failures properly
- 35:50Diversity and redundancy
- 37:54Network communication resilience
- 40:04Component-level resilience patterns
- 44:04Testing resilient systems
- 47:07When is a system resilient?
- 48:57Practical implementation levels
- 54:46Summary and key takeaways
