Justin Sheehy interviewed at Velocity 2011
summary
Argues that you should assume pieces will fail and design for recovery-oriented planning that gets the system back to a good state rather than trying to catch every error, recommends loud component failure combined with overall graceful degradation, warns that adding nodes increases failure frequency so decoupling and avoiding reliance on internal state matters, points to wider availability of clouds and systems like Riak and research such as the Bloom project tying formal models to runnable distributed systems.
AI-written summary · about
related talks
55mGoing Resilient
36mDesigning for failure - architecting fault-tolerant system
31mDesigning for failure
53mResiliency and Availability Design Patterns for the Cloud
41mOnce Upon a Vulnerability: Building Resilience in a Chaotic World
07m"What does system design mean to tester?"
10mInterview on Reactive Applications with Martin Thompson, Todd Montgomery & Viktor Klang
51mPatterns for building resilient software systems
