Don’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
summary
Consultant experience boils down to ten recurring mistakes: teams build distributed monoliths by sharing databases and models, using synchronous HTTP calls that cause cascading slowdowns, and reinventing infra instead of using Kafka or Azure Event Bus and Seq. He states over 90% of microservice projects end up tightly coupled. Practical fixes include the Strangler Fig migration, bounded contexts, per-service data stores, asynchronous queues, circuit breakers, and strict event rules (no new required fields; unknown fields ignored).
AI-written summary · about
chapters (17)
- 0:00Introduction
- 2:55About speaker
- 4:18Monolithic architecture
- 10:39Microservices benefits
- 13:28Distributed monolith
- 17:41Microservices always best?
- 22:42Shared databases mistake
- 29:45Microservices too big
- 31:09Microservices too small
- 33:13Greenfield as microservices
- 37:31Coupling via cross-cutting
- 40:02Synchronous communication
- 43:56Event coupling mistake
- 47:31Automate builds/releases
- 48:35Team organization mismatch
- 51:04Summary
- 52:08Q&A
related talks
01h 04mDon’t Build a Distributed Monolith
43mHow to Avoid Doing Microservices Completely Wrong
43mMicroMonolith - Top anti-patterns of distributed systems
44mMicroservices, Where Did It All Go Wrong
55mMicroservices, Where Did It All Go Wrong
40m10 tips for failing at microservices
36mDo Proper Monoliths before You Do Microservices!
01h 03mMicroservices vs The Distributed Monolith