Reliability Nirvana
summary
Claim: event-driven architecture yields effortless service autonomy by making events the source of truth, trading strict consistency for predictable failure domains and easier recovery. Implements RabbitMQ as the internal bus, Kafka/MSK for high throughput, etcd for short-lived state, S3 + an event archiver for replay, protobuf messages and a small open-source toolchain (plumber open source). Production footprint: ~19–20 services, ~15 million events (~4 KB average, ~100 GB archived). Outcome: deployed and working but culturally and operationally nontrivial.
AI-written summary · about
chapters (16)
- 0:00Reliability nirvana
- 1:14Speaker and disclaimer
- 3:41Defining reliability nirvana
- 8:58Higher reliability challenges
- 12:49Event-driven design
- 17:21Core components
- 22:00Reliability improvements
- 26:52Batch's architecture example
- 27:55Adoption tips and challenges
- 33:14Implementing event-driven systems
- 35:42SRE's role
- 37:07Documentation and culture
- 38:11Benefits and trade-offs
- 40:00Batch's infrastructure stats
- 42:29Further reading
- 44:59Q&A
related talks
41mGetting started with Event-Driven Architectures in 2023
01h 08mEvent Driven Architecture – Enabling Microservices
54mReacting to an Event-Driven World
45mMicro Services and Events: Friends or Foes?
58mImplementing Event-driven Microservices
45mReliable Toolkit for Event-Driven Microservice Architecture
42mCreating event-driven microservices: the why, how and what
26mEvent Driven APIs