When to know you've outgrown your monolith
summary
Stripe’s Ruby monolith bappy serves about 500 million API requests per day and contains ~13 million lines of code which leads to rising CI CPU costs, huge heaps and slow dev loops. The team identifies a large ball of mud that starts at ~26% of the repo and cuts it toward ~13% with Project Skywalker. Results: extracted services load ~83% less code, boost throughput ~30%, make reloads ~3× faster and drop per‑process memory from ~10 GB to ~1–2 GB so the approach works.
AI-written summary · about
chapters (9)
- 0:00Outgrowing a monolith
- 3:26Signs to split the monolith
- 7:37Technical goals for splitting
- 11:05Centralized refactoring approach
- 12:30Project Skywalker at Stripe
- 16:38Keeping momentum during refactor
- 18:02Measured wins after detangling
- 19:47Monolith's future
- 21:52Key takeaways
related talks
39mTaming Monoliths Without Microservices
43mThe history of a Rails monolith
25mBreak up Monoliths and lay them to REST!
57mModularizing the Monolith
28mBringing Your Rails Monolith Along As The Business Grows
12mScaling a Monolith, Is A Four-Letter Word
07mMonolith to over 60 Services
38mFrom Monolith to Nimble