Micro frontends are one of the most oversold patterns in frontend engineering. Every conference talk makes them sound inevitable — the natural evolution of any serious web application. But after working on products where micro frontends were a genuine survival strategy and products where they were a premature optimization that created years of pain, I can tell you: most teams shouldn’t do micro frontends. And the ones that should need to go in with eyes wide open about the real costs.
This page is an honest accounting of both sides. No vendor pitches. No “we adopted micro frontends and everything was amazing.” Just the trade-offs.
“A service is something that is independently deployable and organized around a business capability.” — Sam Newman
That definition matters. If your “micro frontends” can’t deploy independently without breaking each other, you don’t have micro frontends — you have a distributed monolith with extra steps.
What Micro Frontends Actually Solve
Micro frontends solve organizational problems, not technical ones:
| Problem | How Micro Frontends Help |
|---|
| Deployment bottlenecks | Team A ships without waiting for Team B’s release train |
| Team autonomy | Each team owns their slice end-to-end — dependencies, testing, release cadence |
| Isolated failures | If the notifications module crashes, the main app still works |
| Incremental migration | Rewrite one section in a new framework while the rest stays put |
The Real Costs Nobody Talks About
Here’s the bill that conference talks skip over:
| Cost | What It Means in Practice |
|---|
| Shared state complexity | User updates their profile in settings — how does the header find out? You need cross-module communication: custom events, a shared bus, or broadcast channels. |
| UX drift | Button styles diverge. Loading states differ. Spacing is 4px here, 8px there. Users notice. You need a shared design system with strict governance. |
| Bundle bloat | Three micro frontends each bundling React = users download React three times. Externalizing it creates a version compatibility matrix. |
| Performance overhead | Multiple JS bundles, multiple framework instances, coordination overhead. A well-optimized monolith always outperforms a well-optimized micro frontend setup. |
| Tooling investment | Local dev, testing, CI/CD, preview environments — all get harder. “How do I run the whole app locally?” becomes a non-trivial question. |
| Platform team required | Someone has to build and maintain the shell, shared infrastructure, and developer tooling. Budget 2-3 dedicated engineers. |
The biggest mistake I’ve seen: teams adopt micro frontends to solve problems that are actually just poor code organization. If your monolith is painful because of bad architecture, micro frontends give you multiple poorly-architected applications instead of one.
The Decision Matrix
Use this when someone proposes micro frontends. It’s not a formula — it’s a structured way to have an honest conversation.
| Factor | Stay Monolith | Consider Micro Frontends |
|---|
| Team size | < 20 frontend engineers | > 30 engineers, 5+ teams |
| Deploy frequency | Weekly or less | Multiple times daily per team |
| Feature coupling | Features share lots of state and UI | Features are naturally isolated (admin vs user-facing) |
| Tech stack | Single framework, stable | Multiple frameworks or active migration |
| UX consistency | Critical and tightly controlled | Varies by section |
| Time to market | Need to ship fast NOW | Willing to invest in platform for speed LATER |
| Team distribution | Co-located, easy to coordinate | Distributed across timezones |
| Codebase age | < 3 years, well-maintained | 5+ years, legacy sections need replacement |
Integration Approaches Compared
If you do proceed, you need an integration strategy. Each comes with meaningful trade-offs:
| Approach | Shared Dependencies | Framework Lock-in | Isolation | Setup Complexity | Best For |
|---|
| Module Federation (Webpack/Rspack) | Shared singletons (one React) | Webpack/Rspack required | Partial | High | React-based, same-framework teams |
| Import Maps (Native Browser) | Manual via CDN | None | Partial | Medium | Framework-agnostic, progressive teams |
| Iframes | None (full duplication) | None | Complete | Low | Legacy integration, third-party embeds |
| Web Components | Manual | None | Good (Shadow DOM) | Medium | Cross-framework, design systems |
Module Federation is the most common choice for React teams, but it comes with a version compatibility matrix between host and remotes that you’ll be managing forever. Import Maps are simpler conceptually but have less tooling support. Iframes give you complete isolation at the cost of terrible cross-module communication.
The Monolith-First Approach
My default recommendation: start with a monolith and extract micro frontends only when organizational pain demands it.
A well-structured monolith with feature-based folders, lazy-loaded routes, and a shared component library will carry you further than you think. Probably to 20-30 engineers, sometimes further if the team is disciplined.
The key is structuring your monolith with clean feature boundaries from day one:
src/
features/
billing/ ← could become a micro frontend later
components/
hooks/
api/
settings/ ← could become a micro frontend later
components/
hooks/
api/
shared/
components/ ← shared design system
hooks/
utils/
The best micro frontend architecture is the one you don’t build until you need it. Structure your monolith as if each feature folder could become independent. When the organizational pain arrives, you’ll have clean seams to cut along.
Questions to Ask Before Saying Yes
When someone proposes micro frontends, run through this checklist:
- What specific problem are you solving? “Modernization” isn’t specific. “Team A can’t deploy without coordinating with Team B, costing us 2 days per release” is.
- Have you tried solving it within the monolith? Code ownership rules, per-directory deploy pipelines, feature flags — these solve many of the same problems without the architecture change.
- Who will maintain the platform? If you can’t dedicate 2-3 engineers to the shell, shared infrastructure, and tooling, the micro frontends will rot.
- What’s your performance budget? If you can’t tolerate a 20-30% increase in JavaScript payload, this might not be right for your product.
- What’s the migration plan? Nobody goes monolith to micro frontends in one sprint. Plan 6-12 months with clear milestones and the ability to stop if it’s not working.
Micro frontends are a powerful pattern — at the right scale, for the right problems. The sin isn’t adopting them. The sin is adopting them because they sounded good in a conference talk without honestly assessing whether your team is the audience that talk was written for. 