26.3 · Multi-brand apps and SDKs for other teams
When several apps or teams share code, the design question changes from “does it work” to “can other people use it without breaking each other, and can we change it later”.
Mental model. Make differences data and configuration, make contracts small and stable, and make the right usage the easy usage.
Many brands
One codebase, several apps: configuration, theming, build variants and release.
- How do you architect several brands or white-label apps from one codebase: configuration, theming, build variants, release and the risk of forks?
The goal is many apps that differ only where they must, with the shared core staying one codebase. Separate what varies into layers. Identity: each brand that…
SDK design
What you owe the teams that consume your code.
- How do you design an SDK or shared module for other teams: surface area, configuration, errors, concurrency, dependencies, documentation and support?
An internal SDK is a product whose customers are other engineers, and the design rules follow from that. Keep the public surface small: everything public is a…
More in System design & staff+
- 26.1 · Designing a whole feature: the method, a messenger, an offline reader and a store
- 26.2 · Reliability, payload budgets, and analytics and experiments
- 26.4 · RFCs and strategy, estimating, incidents and mentoring, and organisation-level bets
- 26.5 · More whole-feature designs: a feed, a video player, a map, search-as-you-type and notifications
- 26.6 · Collaborative editing, a payments ledger and clocks in sync
- 26.7 · Capacity estimates and retry storms
- 26.8 · A rate limiter, push versus polling, a flight booking app, a swipe deck, an image browser, a ride-hailing rider app and a photo feed API