From a distributed monolith to a microservices solution
summary
A migration story that warns against a false microservices jump and shows concrete fixes: an integration service + thin B2B API, hit with thousands of requests per minute, becomes a distributed monolith when many tiny services share one SQL database and call each other synchronously. The salvaging tactics are specific: use Azure Event Grid for domain events, put storage queues between Event Grid and Functions, apply the outbox pattern, keep one domain responsible for its data and duplicate logic where practicality wins.
AI-written summary · about
chapters (21)
- 0:00Intro
- 1:00Why a monolith
- 2:30microservices vs monolith
- 4:00no silver bullet
- 5:15monolith to microservices
- 6:15integration service
- 8:00API management
- 9:00Using our own API
- 12:30A distributed monolith
- 13:30The next service
- 14:40The integration API
- 15:45The business people
- 19:30The solution
- 22:55Functional domains
- 23:55Implementation details
- 25:15Do repeat yourself
- 29:00loosely coupled code
- 33:25event vs command
- 38:48good practices
- 46:35Bloat defense
- 49:15Open close principle
related talks
48mMicroMonolith
36mDo Proper Monoliths before You Do Microservices!
43mMicroMonolith - Top anti-patterns of distributed systems
42mDo proper monoliths before you do microservices!
42mQ&A - Monolith to Microservices
36mMicroservices Lessons Learned
31mMonolith to Microservices: A Guide to Seamless Transitions
01h 03mFrom Monolith to Microservices: Story and Practice
