Micro-frontends in Practice: Benefits and Pitfalls
Actualizado: 2026-05-03
Micro-frontends apply the microservices idea to the UI: split a large app into pieces that different teams can develop, deploy, and operate independently. The promise is appealing — small autonomous teams that don’t step on each other in a half-million-line React monolith — but after several years of real adoption, there are enough scars to talk about this honestly.
Key takeaways
- The clearest signal to consider micro-frontends is organisational, not technical: four or more teams blocking each other in the same SPA.
- The three dominant patterns are iframes, Module Federation (Webpack 5), and Single-SPA, with distinct trade-offs.
- CSS leakage, dependency versions, shared state, and performance are the production problems that cost the most.
- Without a mature design system, integration pipeline, and platform team, micro-frontends multiply problems instead of solving them.
- A well-structured monorepo (Nx, Turborepo) gives much of the organisational benefit without the operational costs.
When It Makes Sense (And When It Doesn’t)
The clearest signal is organisational, not technical. With a single frontend team, you don’t need micro-frontends. Four or five teams contributing to the same SPA and blocking each other in the pipeline is where the conversation starts to make sense.
Cases where it usually pays off:
- Large applications with clearly separated functional domains (catalogue, checkout, user account).
- Companies with multiple product teams needing independent release cycles.
- Progressive migrations: wrapping a legacy app with modern pieces without rewriting everything.
Cases where it’s premature:
- Startups and small products where coordination happens in a Slack conversation.
- Teams that haven’t established stable internal conventions — you’ll multiply the disorder.
- When the real bottleneck is the backend or design, not frontend development.
The Main Patterns
Iframes (Yes, Still)
The simplest and most isolated option. Each micro-frontend lives in an iframe; communication via postMessage. It works but has known problems: SEO, navigation, accessibility, and the “app inside an app” feel. Useful for integrating legacy internal tools. Poor candidate for fluid user experiences.
Module Federation (Webpack 5)
Webpack 5[1] introduced Module Federation, letting an app dynamically load compiled modules from another app at runtime. It’s the most popular option for serious React/Vue projects.
It allows sharing dependencies (single React across apps) and keeps the unified-SPA feel. Cost: complex Webpack configuration, careful management of shared dependency versions, and debugging that requires patience. Version incompatibility is the number-one source of production incidents.
Single-SPA and Orchestrators
Single-SPA[2] acts as an application router, mounting and unmounting micro-frontends in response to the URL. Good for mixing frameworks (React + Vue + Angular on the same page), although that use case is rarer than it sounds — most end up standardising on one framework.
The Pitfalls Nobody Mentions
After several projects in production, six problems that cost the most:
- CSS leakage. Global styles from one micro-frontend “leak” to others. Solutions: CSS-in-JS, CSS Modules, Shadow DOM. All have their price in complexity or performance.
- Dependency versions. Three teams on three React versions = state corruption and bugs impossible to reproduce. You need strict governance or accept the duplicated bundle cost.
- Shared state. Passing data between micro-frontends without coupling them is hard. Event bus, custom events, shared services — none is elegant.
- Performance. Each micro-frontend brings its own bundle. Without well-configured shared dependencies, total weight can multiply 3-4×.
- End-to-end testing. Testing the complete integration requires additional infrastructure. Per-micro-frontend tests pass; the whole breaks.
- Visual design. Without a mature design system, each team drifts. The page looks stitched together.
Non-negotiable Prerequisites
If you decide to move forward, these must exist beforehand:
- Robust design system with versioned components (ideally as published npm packages).
- Clear and enforced versioning conventions for shared dependencies.
- Integration pipeline testing the full composition, not just each piece.
- Unified observability — errors and metrics must correlate at the page level, not micro-frontend.
- Dedicated platform team maintaining the orchestrator and resolving cross-cutting issues.
Without these, micro-frontends multiply problems instead of solving them.
Cheaper Alternatives
Before jumping to the full pattern, three intermediate options worth evaluating:
- Well-structured monorepo (Nx, Turborepo) with independent builds but unified deploy.
- Component packages published as internal libraries, consumed by a single SPA.
- Bounded contexts in code without separating deploy — logical boundaries, not physical ones.
These options give much of the organisational benefit without the operational costs of micro-frontends.
Micro-frontends pair well with a Figma design system managed as a shared source of truth. The platform team maintaining the orchestrator is analogous to the one described in platform engineering and IDPs. The Grafana Stack for observability is especially important for correlating errors from different micro-frontends in production.
Conclusion
Micro-frontends are a legitimate tool for large organisations with real frontend coordination problems. They aren’t an architectural improvement per se — they’re a transfer of complexity from the organisation to the runtime. That transfer pays off only when human-coordination costs exceed the added technical costs.
If your first reaction reading this was “this sounds complicated”, you probably don’t need them.
