Quietly Strangling the Monolith - a real-world migration of a high traffic monolith
summary
A production monolith (scholar pac on zop and zodb) grows from ~300 to ~2,000 schools with 35–40% yearly growth, serving 3.5k req/s at peak across ten servers, and teams doing 20–30 deployments/day. The team builds a reverse-proxy wrapper and an internal API, moves an assessment module out to Flask + Docker (ECS Fargate), runs Gatling load tests, adds CDN and unified auth, and cuts backend load and operational friction. Outcomes: iterative strangling works, developer velocity improves with feature flags, and the legacy monolith slowly shrinks.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:34Who am I
- 1:23My Energy
- 1:49Disclaimers
- 2:15This is what I did
- 2:34What am I talking about
- 8:03Popular
- 9:07Hug of Death
- 10:24Statutory Requirements
- 11:03Martin Fowler
- 11:16Step 1 Database
- 12:08Microservices
- 13:08Wrapper
- 18:30Big takeaway
- 19:14Things that went wrong
- 24:48Things that were horrendous
- 28:05What we need
- 28:40The Rapper
- 29:55Unexpected benefits
related talks
43m"Monoliths are Simpler" and other lies we tell ourselves
35mLegacy Monolith to Microservices
39mWays out of a monolith
24mModernise your monolith using strangler pattern
41mThe monolith must die! - How to convince managers
36mThe Art of Decomposing Monoliths
20mSplitting the Monolith
40mBreaking the Monolith! Decoupling a Legacy Monolithic Application