Why We Went Down This Path
An enterprise client — a large Indian insurance company — came to us with a problem: they had four development teams (claims, underwriting, customer portal, agent portal) all contributing to a single React monolith. Deployments were a nightmare. One team's bug fix would block another team's feature release. The test suite took 45 minutes, and merge conflicts were a daily occurrence. They wanted each team to deploy independently. Micro-frontends seemed like the answer.
We implemented Module Federation (Webpack 5) across four independently deployable frontends, unified under a shell application. Eighteen months later, we have opinions.
What Actually Worked
Independent deployments: absolutely delivered. Each team ships on their own schedule — the claims team deploys twice a week, the underwriting team deploys every two weeks. No coordination needed, no shared deployment pipeline blocking anyone. This alone justified the project for the client. The time from code merge to production dropped from an average of 4 days (waiting for a coordinated release) to 35 minutes.
Team autonomy: each team owns their technology choices within their micro-frontend. The customer portal team adopted React Query while the claims team uses SWR. The agent portal team experimented with Zustand while others stuck with Redux. This autonomy means teams can optimize for their specific needs without committee approval.
The Shared Design System Problem
We built a shared component library (using Storybook and published as an npm package) for design consistency across micro-frontends. In theory, this gives you consistent UI while allowing team independence. In practice, it's a coordination tax that never goes away.
Updating the shared library requires coordination across all four teams. A breaking change in the Button component means four PRs in four repos. Version mismatches are common — the claims team is on v2.3 of the design system while the underwriting team is still on v2.1 — leading to subtle visual inconsistencies. We spent more time managing the shared library than we expected, roughly 15% of one engineer's time across the 18 months.
Performance Isn't Free
Module Federation adds overhead. Each micro-frontend loads its own React runtime... wait, no — we share React via Module Federation's shared scope. But we still load separate routing, state management, and utility libraries for each micro-frontend. The total JavaScript loaded on a page that renders components from three micro-frontends is about 30% more than a monolith would load. We mitigated this with aggressive code splitting and lazy loading of micro-frontends that aren't immediately visible, but the baseline is higher than a monolith.
The initial load of the shell application plus the first micro-frontend takes about 1.8 seconds on 4G. A comparable monolith would be about 1.3 seconds. For an internal enterprise app, this is acceptable. For a consumer-facing app, it might not be.
The Complexity Tax Is Real
Local development is harder. Running all four micro-frontends locally requires either running four dev servers simultaneously (memory-hungry and confusing) or running one micro-frontend locally while pointing to deployed versions of the others (requires VPN access and introduces network latency in development). We built a custom CLI tool to manage this, but it's still more friction than running a single monolith.
Debugging cross-micro-frontend issues is also harder. When a user reports a bug that spans the shell and two micro-frontends, figuring out which team owns the fix isn't always clear. We established clear ownership boundaries and a "shell team" responsible for cross-cutting concerns, but this added a coordination layer that a monolith doesn't need.
Our Updated Recommendation
Micro-frontends are worth it when you have 3+ teams contributing to the same frontend and deployment coordination is a genuine bottleneck. For smaller teams (1-2 teams), the complexity cost outweighs the independence benefit. Modular monolith with good code ownership and separate CI pipelines per module gives you 80% of the benefit at 20% of the cost.
If we did this project again, we'd probably use the same approach but invest more upfront in the shared development tooling and design system governance. The technology works. The organizational challenges are what actually make or break a micro-frontend architecture.