Practical distributed systems: Building for the real world with chaos engineering
summary
Practical claims: using distributed tracing and chaos engineering together yields observable, resilient microservices. Example results: parallelizing downstream calls cuts tail latency after traces reveal serial bottlenecks; traces expose 800 ms queuing gaps that metrics miss; the system tolerates simulated 80% error rates once retries and timeouts change. Operational practice: weekly Chaos GameDays (tools: sudo halt, iptables, Gremlin, Chaos Monkey) builds on-call skill quickly and validates resilience before customers notice.
AI-written summary · about
chapters (24)
- 0:00Intro
- 1:06Who am I
- 1:30Why do we care
- 1:44Customers
- 2:11Practical distributed systems
- 2:22Observable and resilient
- 5:12The journey of systems
- 7:54Microservices
- 8:49Flame graphs in microservices
- 10:42Distributed tracing
- 11:03Whats wrong
- 12:08Distribute Trace
- 13:25Instrumentation
- 15:24Reality
- 16:35Chaos engineering principles
- 16:59Failure
- 18:14Chaos
- 18:30Chaos Game Day
- 19:42Pseudo Hall
- 21:56Fault tolerance
- 23:01Tools
- 24:44Services resilience
- 26:32Questions
- 27:37Summary
related talks
26mBreaking Systems for Resilience
27mChaos Engineering: The Path to Reliability
01h 02mPractical Chaos Engineering breaking things on purpose to make them more resilient against failure
37mChaos Engineering: The Fine Art of Breaking Stuff in Production on Purpose
26mFrom experimentation to continuous verification
47mChaos Engineering Bottom Up
21mThe Psychology of Chaos Engineering
29mThe Psychology of Chaos Engineering