Reference Architecture: Microfrontend Platform
Product forces
Microfrontends are justified by independent ownership and delivery pressure, not by fashion. They trade runtime and coordination cost for team autonomy.
Architecture sketch
Default decisions
| Area | Default |
|---|---|
| boundaries | domain-aligned, not component-aligned |
| shell | owns routing, session, navigation, layout, cross-app error boundary |
| contracts | shared auth, design system, observability, feature flags |
| deployment | independent deploys with compatibility matrix |
| performance | shared runtime policy, bundle budget, no duplicate heavy dependencies |
| failure | one microfrontend failure does not collapse the shell |
Critical risks
- Splitting by team chart instead of product domain.
- Duplicated frameworks and design-system versions.
- Shared global state crossing app boundaries.
- Shell becoming a hidden monolith.
- Independent deploys without contract testing.
Review checklist
- Is the autonomy gain worth the runtime and governance cost?
- Are boundaries aligned to bounded contexts?
- Can each microfrontend fail independently?
- Are shared contracts versioned and tested?
- Are duplicate runtime costs visible in CI?
Exercises
- Decide whether a modular monolith or microfrontend architecture fits a given organization.
- Define shell-owned and domain-owned responsibilities.
- Create a compatibility matrix for three independently deployed apps.
Source lens
Pair this with Part IV modularity, dependency governance, and frontend platform engineering.