The Art of Decomposing Monoliths
summary
Wix runs 72 million users, 2 PB of data and ~2 billion HTTP requests/day and moves from a dinosaur monolith to 200 microservices; decomposition follows four concrete criteria: separate by SLA (extract a file service so uploads don’t block purchases), by deployment lifecycle (move coupons to a coupon service to avoid rollbacks killing promotions), by shared heavy logic (extract geo lookup instead of sharing DB), and by team ownership. Uses JSON-RPC over HTTP with JDK proxy, retries, idempotency, circuit breakers, feature toggles, gradual traffic shifts, monitoring and postmortems.
AI-written summary · about
chapters (11)
- 0:00Introduction to decomposing monoliths
- 3:18Trade-offs of microservices
- 9:21Four criteria for decomposition
- 12:54Decomposing for SLA differences
- 15:26Decomposing by lifecycle
- 18:22Avoiding code duplication
- 20:54Single team responsibility
- 24:04Gradual microservices adoption
- 26:54Importance of monitoring
- 28:01Learning from failures
- 33:25Q&A session
related talks
01h 01mMonolith Decomposition Patterns
36mDecomposing a monolith - engineering and operational strategies we have gleaned from our experience
42mQ&A - Monolith to Microservices
27mBreak up Monoliths and lay them to REST!
57mSplitting Monolith Application to Microservices
40mBreaking the Monolith! Decoupling a Legacy Monolithic Application
48mMicroMonolith
43mMonolith Carving