Scaling Architecture at Lyft
summary
Lyft Android grows from one developer to ~50–70 engineers, two apps with a shared codebase, and about 800 modules, so architecture focuses on survivable, testable decisions: prefer single-activity with views over fragments, move business logic into use-case/interop layers, use Retrofit + generated clients from Swagger/OpenAPI client generation, Dagger 2 (avoid subcomponents), Bazel for large builds, RxJava or coroutines, feature flags, weekly release trains and splitting apps to speed startup and independent rollouts.
AI-written summary · about
chapters (15)
- 0:00Start
- 0:34Scaling Architecture at Lyft
- 4:20Initial Decision Architecture
- 5:00Jetpack
- 7:12Model View Presenter
- 12:11Google Play in-App Update
- 13:49Continuous Integration Checks
- 14:21Why the Basic Checks Is a Bad Idea
- 16:44Feature Toggles
- 20:31Release Train
- 24:20Dependency Injection
- 25:43Routing
- 33:31File Owners
- 35:48Future Flags for Big Features
- 40:10Design
related talks
01h 00mAndroid builds
24mCreating the Lyft Driver App: Reduce, Reuse, Recycle
37mTackling Android Development at Scale
31mCreating the Lyft Driver App: Reduce, Reuse, Recycle
39mScaling an Android App from 1 to 100 developers with modularization.
49mBuilding for the future at Snapchat
15mArchitecting Amp: Android integration with embedded systems
43mThe Engineering Playbook for Growing Android Teams