Micro-frontends promise the same benefits for the frontend that microservices brought to the backend — independent deployment, autonomous teams, technology flexibility. But after evaluating the pattern for two client projects in October, we found that the decision is rarely straightforward.
What micro-frontends actually solve
The primary problem micro-frontends address is organizational, not technical. When multiple teams work on the same frontend codebase, coordination costs grow. Merge conflicts increase. Deployment schedules conflict. A bug in Team A’s code blocks Team B’s release.
Micro-frontends let each team own a vertical slice of the application — a section of the page, a route, or a feature — and deploy it independently. The integration happens at the shell level, not the build level.
If you have one team building one application, micro-frontends add complexity without solving a real problem.
The integration patterns
Build-time integration. Each micro-frontend is published as a package. The shell application installs and bundles them at build time. This is the simplest pattern. It sacrifices independent deployment — the shell must rebuild to include a new version — but keeps the runtime simple.
Runtime integration via module federation. Webpack Module Federation or its Vite equivalent allows the shell to load micro-frontends at runtime from separate bundles. Teams can deploy independently. The cost is increased runtime complexity, version management challenges, and shared dependency coordination.
Server-side composition. An edge or server layer assembles fragments from different micro-frontends into a single HTML response. This pattern works well for content-heavy sites where each section is relatively independent. It avoids client-side composition overhead but requires a robust stitching layer.
iframe isolation. Each micro-frontend runs in an iframe. Complete isolation — different frameworks, different versions, different everything. The cost is significant: no shared state, communication via postMessage, inconsistent scroll behavior, and accessibility challenges.
When we recommended it
For a large financial services dashboard with four development teams across three time zones, micro-frontends made sense. Each team owned a dashboard panel — accounts, transactions, analytics, and settings. They deployed on different schedules. They had different testing requirements.
We used runtime module federation. Each team builds and deploys independently. The shell loads panels on demand. A bug in the analytics panel does not affect the accounts view. Teams ship when they are ready, not when everyone is ready.
When we recommended against it
For a marketing site with a blog, product pages, and a contact form, micro-frontends would have been absurd. One team, one codebase, one deployment. The coordination problem does not exist, so the solution creates overhead with no benefit.
We also advised against it for a two-team project where the teams worked closely together and deployed on the same schedule. The overhead of maintaining module federation configuration, shared dependency management, and cross-team integration testing outweighed the independence benefit.
The hidden costs
Shared design consistency. When teams can use different component libraries or styling approaches, visual consistency suffers. You need a shared design system with strict governance to keep the experience cohesive.
Cross-cutting concerns. Authentication, routing, error handling, and analytics need to work across all micro-frontends. Coordinating these without tight coupling is genuinely difficult.
Performance. Multiple bundles mean more JavaScript, more network requests, and more potential for duplicate dependencies. Without careful optimization, micro-frontends can deliver a worse user experience than a monolith.
Developer experience. Running the full application locally requires orchestrating multiple services. This is manageable with good tooling but significantly more complex than starting a single dev server.
Our decision framework
We now evaluate micro-frontends with four questions:
- Do you have more than two teams contributing to the same frontend?
- Do those teams need to deploy on independent schedules?
- Are the teams’ domains sufficiently independent that they rarely need to change each other’s code?
- Are you prepared to invest in the supporting infrastructure — shared design system, integration testing, module federation configuration?
If all four answers are yes, micro-frontends are worth evaluating. If any answer is no, a well-structured monolith will serve you better.
The architecture should solve the problem you actually have, not the problem you think you might have someday.
