A team proposes micro-frontends. What genuinely justifies them, and what is the usual cost?
Show the full answer Hide the answer
What genuinely justifies them
Independent deployment by teams that are genuinely blocked by a shared release. If several teams must coordinate every release of one application and that coordination is the constraint, splitting the deployment addresses it.
Also: genuinely different technology requirements — a legacy surface being incrementally replaced, or an acquired product being integrated.
Team count alone is not a justification, and neither is "different domains", which describes a module boundary rather than a deployment one.
The usual cost
- Duplicated framework and library payload unless carefully shared, which directly degrades the thing that matters most on a constrained device.
- Inconsistent experience, since independently deployed surfaces drift in behaviour, style and interaction patterns.
- Harder performance work, because the total page weight is nobody's responsibility and each team optimises their own fragment.
- Cross-fragment state, which is where most of the accidental complexity accumulates — the basket, the session, the notification count.
- Debugging across boundaries, which is meaningfully harder in a browser than on a server.
The test to apply
Can one team change, deploy and roll back without telling the others? If the answer is no — if a shared component library must be versioned in lockstep, if a change requires coordinated releases — the boundary is delivering cost without independence, which is the entire point of it.
The cheaper alternative that is usually sufficient
A monorepo with clear module boundaries and independent build outputs. It gives ownership, enforced dependency rules and code sharing without runtime composition — and it retains a single performance budget with a single owner, which is the property most often lost.
Micro-frontends are the frontend's version of microservices, and they carry the same lesson: the boundary is justified by independent deployability and by nothing else, and a boundary that does not deliver it is pure overhead.