Measuring Microservices
summary
Claims that system health is best judged by message flow rates and simple pattern-derived checks rather than per-service metrics, uses invariants as ratios (actor, subscriber, chain patterns) to detect regressions on deploy, and recommends lightweight formal methods such as TLA+ to model risk. Cites an Amazon simulation that finds a data-loss bug ~15–16 steps deep. Implements dashboards counting messages and ratio alerts, enabling immediate rollback when flows deviate and used in production with nearForm and Senecajs.org.
AI-written summary · about
chapters (21)
- 0:00Intro
- 1:24Our Experiences
- 3:20What are Microservices
- 5:51Message flow rate
- 6:57A practical example
- 8:26Traditional measures
- 9:04Flow rates
- 9:58Actor pattern
- 10:16Subscriber pattern
- 11:13Invoice pattern
- 11:36Message chain
- 11:58Why build microservices
- 13:05Risk reduction
- 14:11Unit tests
- 15:00Microservices make things worse
- 15:31Deploy systems that really work
- 15:55Measurement of the production system
- 16:08Formal methods
- 18:50Invariance
- 19:33Example
- 28:19Summary
related talks
40mMeasuring Micro-services
36mA practical tale of assessing a Microservices Architecture
51mResponsible Microservices
46mSurviving microservices
31mHundreds of Microservices without breaking your APIs
52mSurviving in a Microservices Team
33mEffective observability in microservice architectures
35mMonitoring Microservices