From 30 Minutes Down to 10: Taming our Monolith's CI Build Times
Article Summary
Cash App's monolith CI builds were taking 30 minutes at p50. Developers were stuck waiting through multiple build cycles just to get a green merge.
The Cash App team tackled their legacy 'Franklin' service, a million-line monolith that still powers critical functionality. Despite migrating to microservices, this codebase kept growing and its slow builds were crushing developer productivity.
Key Takeaways
- Cut p50 build times from 30 to 10 minutes, p99 from 45 to 22 minutes
- Modularized codebase to enable Gradle remote build cache with higher hit ratios
- Started test workers eagerly during compilation, saving several minutes per build
- Cached expensive test customer setups, reusing them across hundreds of integration tests
- Distributed 10,000+ tests by historical duration instead of count for balanced shards
Through nine targeted optimizations (not just throwing money at more workers), Cash App reduced their monolith's CI build times by 67% at p50.
About This Article
Franklin's codebase had accumulated dead code and wasn't properly modularized. With over a million lines of code and thousands of dependencies, any change required a full rebuild.
Yissachar Radcliffe's team removed tens of thousands of lines of dead code and split the monolith into multiple modules. This let Gradle's remote build cache identify unchanged components and compile them in parallel.
The modularization improved cache hit ratios and enabled more parallel compilation. Build times dropped 67% overall, falling from 30 minutes to 10 minutes at the p50 mark.