Traveloka • Ahmad Fadli Basyari • Jun 28, 2018

3 Years of Android Development at Traveloka

Article Summary

Ahmad Fadli Basyari from Traveloka watched build times balloon from 3 minutes to 10 minutes as the app grew from 3 products to 20+. His team's solution? Rewrite the entire app twice in three years.

Traveloka's Android team scaled from 5 to 30+ engineers between 2015-2018, shipping 60 releases and growing from a messy single-module app to a sophisticated multi-module architecture. The journey involved two complete rewrites, multiple failed attempts at modularization, and hard lessons about technical debt.

Key Takeaways

First modularization attempt failed: still hit 65k method limit despite multi-module design
Separating by feature (not layer) cut build time from 10 minutes to 2-3 minutes
DataBinding generated 7,500+ duplicate classes (15 modules × 500 XMLs) causing memory crashes
No-op modules let developers mock unused products during development for faster builds
Multi-module forced better practices: coding against interfaces instead of direct coupling

Critical Insight

Traveloka reduced build times by 70% through feature-based modularization, but only after learning that layer-based separation and premature optimization don't scale.

The article reveals why their first modularization attempt was scrapped after months of work, and the surprising comfort zone trap that made the second attempt nearly impossible.

About This Article

Problem

Traveloka's Android app expanded to over 20 products with 35 minor and 25 major releases. The codebase had serious structural issues. API calls were scattered throughout Activities and Fragments, singleton classes managed shared state, and the team couldn't add new features without risking the whole system.

Solution

Ahmad Fadli Basyari's team adopted the MVP-VM design pattern with Android DataBinding. This separated the presenter, view model, and model layers into distinct concerns. They treated architecture as ongoing work rather than something to plan once upfront.

Impact

By August 2016, the new framework let them hire 25+ more Android engineers and launch 20+ products while staying under the 65k method limit. Later, they realized that organizing code by layers wasn't enough. They needed to split things by feature instead to get better build performance.