Module Federation
also called Micro Frontends
Composing a frontend from independently deployed pieces — solving an organisational problem at a real technical cost.
Definition
Module federation lets separately built and deployed frontend bundles load each other's modules at runtime, so different teams can own and release parts of one interface independently.
The problem it addresses
A single frontend owned by many teams becomes a release bottleneck. Every change waits for a shared build, a shared test suite and a shared release. With enough teams, that coordination cost dominates.
The problem is organisational, and the solution is technical — which is exactly the shape that produces over-adoption.
What it costs
- Runtime failure modes. A remote module fails to load; the host must degrade rather than break. Any federated boundary needs an error boundary and a fallback.
- Shared dependency management. Two teams on different versions of the same framework means either duplicated payload or a coordination requirement that removes the independence.
- Consistency. Design systems, accessibility standards and behaviour must be maintained across independently developed pieces, which requires deliberate effort.
- Performance. Multiple bundles, multiple network requests, harder tree-shaking.
- Debugging. A failure spans code from several builds, several teams and several repositories.
When it is justified
- Many teams on one interface, where the release bottleneck is measurable.
- Genuinely independent areas of the product, with little shared state or navigation.
- Different release cadences, particularly where a regulated area must be released separately.
- Incremental migration, using it to run old and new frontends side by side — frequently the strongest and most bounded use.
When it is not
Small teams. Highly interconnected interfaces. Products where consistency is a primary quality. In those cases a well-modularised single application with enforced internal boundaries gives the boundaries without the runtime cost — the same argument as the modular monolith, one layer up.
Failure scenarios
- Adopted for technical reasons when there was no organisational bottleneck.
- A remote failing to load and breaking the host.
- Shared dependencies unmanaged, producing bloat or lockstep coupling.
- Inconsistent experience across boundaries the user does not perceive as separate.
- Shared state across federated modules, which recreates the coupling that was being removed.
Interview question
"When do micro frontends solve a real problem, and what do they cost?"