Dagger and Multi-Module Architecture in Traveloka Android App
Article Summary
Alifa Nurani Putri and Yusuf Cahyo Nugroho from Traveloka reveal how their single Dagger component ballooned to 17,705 lines of code across 25+ products. Their refactoring journey cut initialization time and build times while preparing for Dynamic Feature Modules.
Traveloka's Android team started with a simple Dagger setup in 2016, but as they scaled to 25+ products, their AppComponent became a god object with 82 modules and 36 subcomponents. This deep dive walks through their multi-year refactoring journey to fix build times, memory issues, and enable modularization.
Key Takeaways
- Single AppComponent grew to 17,705 generated lines with 82 modules and 36 subcomponents
- Refactoring one product module reduced Dagger initialization from 357ms to 219ms
- Introduced product api and base modules to break diamond-shaped dependency pattern
- Dagger-bridge layer decreased incremental build time by skipping app module recompilation
- Cross-sell architecture required contract-based approach to avoid circular dependencies
By splitting their monolithic Dagger component into product-specific api, base, and internal modules, Traveloka reduced initialization time by 39% and significantly improved incremental build times.
About This Article
Traveloka's app module depended on all 25+ product modules in a diamond pattern. This meant that whenever any product module's public code changed, the app had to recompile during incremental builds. The result was 2+ minutes added to build times.
The team added a dagger-bridge pseudo-decoupling layer between the product modules and the app module. This isolated the product modules so only the bridge layer needed rebuilding when product code changed.
Incremental build times improved because Gradle skipped critical tasks like processDebugAnnotationsWithJavac and compileDebugJavaWithJavac when changes stayed within product modules. Gradle Enterprise analysis confirmed this optimization.