Micro-Frontends Explained: When to Use Them (and When Not To)

This blog already has a production case study covering a real micro-frontend architecture. This post is the general version of that same reasoning — when the pattern earns its cost, and, just as importantly, when it doesn't.

What it actually is

Instead of one frontend application owned by one team, the frontend is split into independently developed, independently deployed modules — composed together at runtime by a thin shell application. Conceptually the frontend equivalent of backend microservices: independent deployability as the actual goal, not a specific technology choice.

The real problem it solves

A single, large frontend app with multiple teams shipping to it means every team's release is coupled to every other team's release schedule and risk — one team's bug blocks everyone's deploy. Independent modules mean one team ships on its own schedule, and a bug in one module doesn't force every other team to hold their release.

The real cost, honestly

• Shared concerns — a consistent design system, a shared authentication state, a common way to navigate between modules — all need deliberate, ongoing coordination, or every module quietly reinvents them slightly differently.
• Runtime composition has real technical cost — getting independently-built modules to share dependencies efficiently instead of each shipping its own copy of React (multiplying bundle size) requires real infrastructure (Module Federation or similar), not just "put them on the same page."
• Debugging crosses a real module boundary — a bug that spans two modules is genuinely harder to trace than the same bug inside one unified codebase, because the two pieces were built, tested, and deployed independently.

The honest decision rule

It's worth the real, ongoing coordination cost specifically when independent deployability is an actual, felt constraint — multiple teams genuinely blocked by each other's release cycles, as it was for the Quote Management System's insurance product lines. It's the wrong default for a single team or a solo developer, where the coordination cost is pure overhead with no corresponding benefit — exactly the same 'is this abstraction actually earning its cost' judgment the component-architecture post in the why-React series makes about component boundaries, one level up in scale.