Android App Architecture at Scale

At scale, the hardest architecture problems are organisational and systemic: how 10 teams ship independently without breaking each other, how features share user state consistently, how the app stays fast as everyone adds code, and how decisions stay coherent across years.

The shape of a large Android app

1. Strong boundaries

• Feature modules with public API modules for cross-feature contracts. See Modularization Strategies.
• Enforced dependency rules in CI, not just conventions.
• Teams own modules (CODEOWNERS), with clear on-call and quality responsibility.

2. Shared state, done deliberately

User session, cart contents and entitlements are needed by many features. Put them in shared services with observable APIs, and a single source of truth for each:

interface SessionService {
    val session: StateFlow<Session>               // SignedOut | SignedIn(user, entitlements)
    suspend fun signOut()
}

sealed interface Session {
    data object SignedOut : Session
    data class SignedIn(val userId: String, val entitlements: Set<String>) : Session
}
// Features observe; only the auth feature mutates via its own API.

3. Navigation across features

Features expose route keys or entry points through API modules. The app shell assembles the navigation graph, so features never reference each other's screens directly. Deep links resolve to keys centrally. See Navigation in Compose.

4. Performance budgets

• Set budgets: cold start, frame metrics on key screens, APK size, memory.
• Run Macrobenchmarks in CI, and alert on regressions per PR or nightly.
• Control startup centrally: features register initialisers with priorities, so nobody adds work to Application.onCreate unreviewed.

5. Experimentation and flags

Large apps run many experiments at once. Centralise flag evaluation and exposure logging, keep flag reads out of deep business logic (inject decisions), and clean up flags after launch. See Scaling Across Teams.

6. Consistency and governance

• A design system module with screenshot tests.
• Architecture decision records and lightweight design reviews for cross-cutting changes.
• Templates and convention plugins for new features.
• Lint rules encoding team conventions.

7. Data consistency at scale

Multiple features caching the same entities leads to inconsistency. Prefer shared repositories over a common database for core entities, and event-driven invalidation (for example push-triggered refresh) for data that changes server-side.

Evolution stages

Frequently asked questions

Conclusion

Architecture at scale means enforced boundaries, deliberate shared state, centrally assembled navigation, performance budgets in CI, managed experimentation and lightweight governance, so many teams can ship independently while the app stays coherent and fast.

Next step: keep builds fast as the codebase grows with Multi-Module Gradle Builds and Build Optimization.