Microservices vs The Distributed Monolith
summary
Covers why splitting a messy monolith into services often produces a common library that reintroduces coupling, why interdependent deployments and temporal coupling cause rollbacks and outages, and why race conditions are hard to reproduce; shows an event driven architecture using a message bus (RabbitMQ or Kafka) with compensating events, versioned APIs and feature flags to avoid distributed transactions, and points out the availability math (one 99.7% service versus ten drops to roughly 99.7% → 97%) as a concrete risk.
AI-written summary · about
chapters (12)
- 0:00Microservices vs monoliths
- 1:07Microservice architecture features
- 8:13Microservices advantages
- 10:38Microservices challenges
- 15:35Distributed monolith explained
- 16:58Shared common library mistake
- 24:21Interdependent deployment risks
- 30:38Race conditions in systems
- 35:59Temporal coupling and transactions
- 42:44Avoiding microservice coupling
- 45:35Event-driven decoupling
- 58:38Key takeaways trade-offs
related talks
48mMicroservices vs The Distributed Monolith
43mHow to Avoid Doing Microservices Completely Wrong
59mHow to Escape The Distributed Monolith
01h 04mDon’t Build a Distributed Monolith
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong
01h 00mMicroservices, Where Did It All Go Wrong?
43mMicroMonolith - Top anti-patterns of distributed systems
50mEmbracing Microservices