Breaking up the App Module Monolith: The Story of Robinhood's Android App
Article Summary
Robinhood's Android app hit a wall: 100k+ dex count, skyrocketing build times, and features breaking each other. Sound familiar?
Jin Cao from Robinhood Engineering shares their journey from a 2-module monolith to 30+ independent feature modules. This is the story of how rapid growth turned their clean codebase into a tightly coupled mess, and what they did about it.
Key Takeaways
- Started with just 2 modules (librobinhood and app), everything accessible to everything
- Bottom nav bar reuse caused silent breakage across unrelated features
- Extracted 30+ modules with strict rule: no feature depends on another feature
- Created lib-navigation for cross-feature routing without explicit dependencies
- Duplicated code when features only looked similar, avoiding over-abstraction
Modularization stabilized incremental build times despite continued feature growth and gave engineers confidence to make isolated changes without breaking other features.
About This Article
Robinhood's Android app had three separate OkHttpClient definitions scattered across eight Retrofit interfaces. This inconsistency made the code hard to maintain and created confusion about how these components connected.
Jin Cao's team created independent library modules like lib-analytics with clear responsibilities and dependencies. They used Dagger modules to configure each library separately, keeping everything organized.
Engineers could now make changes to individual features without worrying about breaking something else. The team enforced strict rules: feature modules don't depend on each other, and shared code only gets extracted into feature-lib modules when it makes sense conceptually.