Chaos Engineering on the Death Star
summary
A concrete case study follows Maia as the Death Star PR site gets hit with real failures and experiments that reveal what actually breaks: 503 responses from an upload service that cause silent failures, a traffic spike from Hoth that causes severe latency, and a 401 from third-party API that kills subscription pages. Quick mitigations like a banner reduce user confusion but payments still fail; suggested tools include flu shot chaos RB and chaos Orca to inject latency, exceptions, and CPU/memory pressure.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:28App layer chaos in Ruby
- 7:48Cloud outages in prod
- 10:02High traffic slowdowns
- 12:51Third-party API failures
- 14:16Start small with observability
- 16:02Leadership buy-in
- 17:51Ruby chaos tools
- 19:59Closing
related talks
16mDeath Star Security: A Realtime Look At How A Site Is Hacked
27mExecuting Chaos Engineering in Production at a Critical Financial Institution
25mChaos Engineering Applied To the FinTech Domain
37mThreat Modelling: Star Wars Edition
01h 01mEmbrace chaos to achieve stability
37mUse Chaos Testing to Build Resilience in the Software
54mControlled Chaos: The Inevitable Marriage of DevOps & Security
38mCreating chaos in containers