Coupang Android Architecture Part 3
Article Summary
Seongchul Park from Coupang reveals how their Android team escaped the 'big ball of mud' by rethinking how they organize code. Spoiler: it wasn't just about modules.
After splitting Coupang's Android app into 13 core modules, the team still had a mess of tangled dependencies. The culprit? They were organizing code by component types (activities, fragments, adapters) instead of by business features. This is Part 3 of their architecture transformation series.
Key Takeaways
- Feature-based packaging beats component-based for scalability and removability
- Used marker interfaces to avoid rewriting ProGuard configs after every package change
- Visualization tools like APK Dependency Graph showed dramatic reduction in coupling
- Aligned package structure with team domains (search, login, cart) to distribute work
Coupang transformed their Android codebase from a tangled dependency web into cleanly separated feature packages that teams can modify and remove independently.
About This Article
Coupang split their codebase into 13 core components, but the feature modules still organized packages by component type: activities, fragments, adapters. This structure created tangled dependencies that made the code harder to maintain and scale.
They reorganized packages around business features instead of component types. Common code went into top-level 'common' packages, while feature-specific code lived in its own packages. Android Studio's refactoring tools and marker interfaces on DTOs helped automate the ProGuard configuration updates.
After repackaging, the APK Dependency Graph showed much less coupling between components. Teams could now modify, remove, or expand individual features like search, login, and cart without triggering a cascade of dependency updates across the codebase.