Don’t Build a Distributed Monolith
summary
Claims that systems built as “microservices” often become distributed monoliths that perform worse than either a monolith or true microservices, and lists 10 common mistakes plus a bonus: shared databases, synchronous REST calls between services causing cascading slowdowns, breaking event contracts, lack of CI/CD, wrong service size, coupling via shared logging or models, and mismatched teams. Recommends event-driven messaging (use Kafka or cloud event buses, don’t roll your own), duplicate owned data via events with rules (optional new fields, ignore unknowns, default values, new event types for breaking changes), and automate CI/CD before moving to microservices.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:47Distributed monolith horror
- 11:12Monoliths vs microservices
- 16:06What is a distributed monolith
- 24:15Microservices pitfalls
- 34:36Microservices too big or too small
- 37:47Monolith to microservices
- 44:28Coupling via cross-cutting
- 46:56Avoid synchronous calls
- 50:49Breaking event contracts
- 52:58Automating builds/releases
- 54:21Unencapsulated design
- 56:06Mismatched team structures
- 59:16Monolith vs microservices
- 1:00:19Further reading & Q&A
related talks
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
43mHow to Avoid Doing Microservices Completely Wrong
43mMicroMonolith - Top anti-patterns of distributed systems
01h 03mMicroservices vs The Distributed Monolith
44mMicroservices, Where Did It All Go Wrong
40m10 tips for failing at microservices
01h 08mWhy you should never build Microservices - and why we do it anyway
55mMicroservices, Where Did It All Go Wrong