Microfrontend Architecture
A system-design guide for splitting frontend domains across teams while keeping routing, shared dependencies, UI consistency, deployment, and runtime failures understandable.
Choose the boundary
A useful microfrontend boundary aligns with a durable business capability and a team that can own its delivery end to end.
- Avoid splitting by tiny UI fragments
- Define ownership before technology
- Keep cross-domain data contracts explicit
Composition strategy
Composition can happen at build time, server time, route level, or in the browser. Pick the simplest mechanism that meets independent-delivery requirements.
- Route-level composition is easiest to reason about
- Runtime composition increases failure modes
- Design loading and fallback behavior for every remote boundary
Shared dependencies
Framework, design-system, authentication, analytics, and utility dependencies need version and compatibility policies.
- Do not assume singleton compatibility
- Publish stable shared contracts
- Keep design tokens and primitives synchronized
- Avoid hidden global state between independently deployed apps
Routing & communication
Cross-app communication should look more like API design than ad-hoc event wiring.
- Prefer URL and backend state for durable coordination
- Use typed events only for narrow runtime signals
- Document ownership of navigation and authentication
Operations
Independent deployment means independent failure. Observability and release governance must be designed before scale arrives.
- Trace remote loading failures
- Track version combinations
- Use contract tests
- Support progressive rollout and rollback