Microservices vs The Distributed Monolith
summary
Describes why a brittle monolith refactored into many tiny services easily becomes a distributed monolith: a bloated shared library, synchronized deployments, and temporal coupling that makes one request trigger many synchronous calls. Cites PHP local method calls in microseconds vs network calls in tens–hundreds ms — roughly 100,000x slower — and a real case where 14 backend calls render a page in 15 seconds. Recommends async, event-driven message bus (Kafka), projections, process managers, feature flags, and smaller focused libraries with semantic versioning.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:05Monolith vs Microservices
- 1:55Key features of a monolith architecture
- 4:20Key features of a microservice architecture
- 9:20Disadvantages of microservices
- 17:24What is the solution?
- 25:41Booking a ticket
- 26:47What makes this so bad?
- 30:17Decoupling microservices
- 33:34A familiar model
- 34:00Event sourcing example
- 36:14Projections
- 38:23Process managers
- 39:59Event replays
- 40:43Advantages of event driven architecture
related talks
01h 03mMicroservices vs The Distributed Monolith
47mMicroservices? Monoliths? An Annoying Discussion!
23mMicroservices in a Monolith
43mMicroMonolith - Top anti-patterns of distributed systems
59mHow to Escape The Distributed Monolith
19mMicroservices vs. Monolith for Scalability and Efficiency
01h 04mDon’t Build a Distributed Monolith
53mDon’t Build a Distributed Monolith: How to Avoid Doing Microservices Wrong