Micro-frontends: when you need them and what they cost

Micro-frontends split a large interface into independent parts that different teams build and ship separately. They make sense when several teams work on one product and a shared release slows everyone down. For a small team, micro-frontends usually bring more complexity than benefit — a modular monolith fits better.

Here are the problems micro-frontends solve, how they are assembled, what they cost and what to choose instead.

What problems do micro-frontends solve?

Micro-frontends solve organisational problems, not technical ones: they give teams independence. When ten people from different teams edit one frontend repository, releasing one feature waits on everyone else's review and code conflicts become daily.

What micro-frontends give you:

• independent releases — the catalogue team ships without waiting for the payments team;
• clear ownership — each part of the interface belongs to one team;
• gradual migration — an old interface is replaced piece by piece instead of rewritten at once;
• failure isolation — an error in one widget does not bring down the whole page.

It is the same logic as backend microservices, with the same trade-offs — see monolith vs microservices.

How are micro-frontends assembled?

Interface parts are assembled into one page on the server, in the browser at runtime or through iframes. The choice depends on SEO, load speed and isolation requirements.

Method	How it works	Pros	Cons
Server-side composition	The server stitches HTML from fragments	Good for SEO and speed	More complex infrastructure
Module Federation	The browser loads modules from other apps	Shared dependencies, flexibility	Version coupling, harder debugging
Web Components	Parts are custom elements	Framework-agnostic	Styling and SSR limitations
iframe	Each part is a separate page	Full isolation	Awkward navigation, weight, accessibility

Photo: Unsplash

What do micro-frontends cost?

Micro-frontends complicate everything that used to be shared: design, dependencies, routing, testing and performance. Without discipline, users get a page with three framework versions, mismatched buttons and slow loading.

The main costs:

1. Performance. Each part may pull its own libraries, increasing JavaScript size and load time.
2. Consistent design. You need a shared design system or the interface drifts apart — see design system: when you need one.
3. Shared data. Authentication, cart and user settings must be available to every part.
4. Infrastructure. Separate builds, deployments, versions and monitoring for every part.
5. End-to-end testing. Parts ship independently but must work together.

What should you choose instead?

A small team is usually better served by a modular monolith: one application split into modules with clear boundaries and dependency rules. It brings order to the code and clear ownership without separate infrastructure for each part.

Signs you do not need micro-frontends yet:

• one or two teams work on the frontend;
• releases do not block each other for more than a day;
• the product uses one framework and no migration is planned;
• load speed and SEO of public pages matter.

Signs it is time:

• three or more teams constantly conflict in one repository;
• an old interface must be replaced gradually without stopping development;
• different product areas have different release cycles and owners.

On choosing a framework and typing, see Vue vs React and TypeScript on the frontend.

How do you introduce micro-frontends once decided?

Introduce them gradually: start with a shell that handles navigation and authentication, and move one of the most independent parts into a separate application. Move the rest only once the setup proves itself.

• agree on one framework and shared versions of key libraries;
• publish the design system as a separate package;
• define how parts communicate: events, a shared store or the URL;
• track JavaScript size per page in CI.

In short

• Micro-frontends solve an organisational problem — independence for several teams.
• Assembly methods: server-side, Module Federation, Web Components, iframes.
• The cost is performance, consistent design, shared data and infrastructure.
• One or two teams are usually better off with a modular monolith.
• Roll out gradually: a shell, one independent part, then the rest.