advanced 1 min answer

A team proposes micro-frontends. What genuinely justifies them, and what is the usual cost?

credmicro-frontendsindependencecouplingperformance
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.