Q&A - Monolith to Microservices
summary
Advocates require a clear, pressing problem before splitting a monolith, not fashion; many teams start with one to three services and scale the dial up, while one bank runs ~1,600 services successfully. Migration uses the strangler pattern by intercepting traffic via HTTP proxies or UI widgets and moving features incrementally. Data must be decomposed with logical isolation (sometimes on shared physical DBs) and expect caching and read‑replica latency windows that force eventual consistency tradeoffs. Map and shift ownership tasks gradually to avoid organizational shock.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:18When should I move to Microservices
- 4:22Microservices
- 8:22Microservices vs Monolith
- 11:49Independent deployment
- 15:19Shifting ownership
- 17:38Monolith vs Microservices
- 21:23Etsy
- 24:25Strangler pattern
- 28:15UI decomposition
- 30:40Database decomposition
- 33:35Breaking a database apart
- 41:30Outro
related talks
39mConsidering Migrating a Monolith to Microservices?
48mMicroMonolith
43mMicroMonolith - Top anti-patterns of distributed systems
32mSplitting the monolith
01h 01mMonolith Decomposition Patterns
31mMonolith to Microservices: A Guide to Seamless Transitions
38mFrom Monolith to Microservices
33mFireside chat - Monoliths, Microservices & Modernization – Practical Strategies