MicroMonolith
summary
A team migrates a .NET monolith with one huge database and ~20–30 engineers into hundreds of services over a few years, cutting a 60‑minute deployment cycle to daily releases but creating a tangled distributed monolith where services call one another synchronously. Root causes include synchronous HTTP integration, a single relational DB forcing shared schemas, and lack of domain boundaries. Practical fixes: RabbitMQ messaging, CDC from the DB to build per‑service read stores, eventual consistency and schema‑per‑service migrations.
AI-written summary · about
chapters (6)
- 0:00Introduction to the topic
- 5:12Legacy system transformation
- 11:12Anti-pattern: Micromonolith
- 21:34Integration strategies
- 28:50Managing distributed data
- 37:19Conclusion and Q&A
related talks
43mMicroMonolith - Top anti-patterns of distributed systems
42mQ&A - Monolith to Microservices
54mFrom a distributed monolith to a microservices solution
23mOn the road from Monolith to Micro
32mSplitting the monolith
42mDo proper monoliths before you do microservices!
36mDo Proper Monoliths before You Do Microservices!
35mLegacy Monolith to Microservices
