Micro Frontends: What They Are and When to Use Them

Development

Business

A micro frontend architecture splits a browser application into independently built and deployed slices, each owned end to end by a single team. One codebase that every team queues to change becomes several that each team ships on its own pipeline. The frontend stops being the bottleneck behind a microservices back end.

That is the whole promise. It is not free. You gain independent deployment, per-slice technology choices and smaller bundles; you take on a shared platform to maintain, a design system to police across teams, and a coordination cost that only a handful of teams can absorb. Below three or four autonomous teams, the overhead usually costs more than the monolith it replaces.

So is the question whether micro frontends work? No. The question is whether your organisation is at the point where they pay off. This post covers what a micro frontend is, how the architecture sits over microservices, the gains and costs as they actually land in delivery, what the platform costs to run, and a three-gate readiness check you can put your own estate through before committing.

Find out here how to find skilled React Developers

What is a micro frontend?

A micro frontend is composed of several small, autonomous, modular components. The modules are self-contained, and other pages can reuse them. You can write those components in any programming language: JavaScript and JavaScript frameworks are the popular choice, but anything that compiles and packages into a JavaScript bundle can be imported and composed by the rest of the frontend.

Think of a shopping centre. One roof, one entrance, one car park, shared signage, and behind each shopfront a different team fitting out its own space on its own schedule. Shoppers experience a single place; the shops are run by whoever knows that trade best.

In micro frontend architecture, that is exactly the arrangement. You break the monolithic application into smaller pieces and code, test and deploy each fragment separately, so cross-functional teams can develop each component, from a database to a user interface, independently. What keeps the seams hidden is the shell and the shared design system: the shell renders every slice into one page with one navigation and one session, and the design system gives them the same components and the same styling.

The pattern was named and catalogued at micro-frontends.org, and Martin Fowler's team published the canonical write-up of the micro frontends pattern, including the integration styles we get to further down.

Well-known companies that use micro frontends

Here are a few well-known companies that use micro frontends:

IKEA: a European furniture retailer with a large online shopping estate. Its engineering team's talks on composing pages from independently owned fragments are among the reference cases collected at micro-frontends.org.
DAZN: a European sports streaming service operating across nine countries. Luca Mezzalira — DAZN's former VP of architecture, now a principal solutions architect at AWS — documents its approach in his O'Reilly book Building Micro-Frontends, updated in a 2025 second edition (Building Micro-Frontends: Distributed Systems for the Frontend).
Upwork: a freelancing network that connects independent business professionals all around the world.
Spotify: this streaming provider assembled desktop applications from independently developed frontend slices composed in a shell, the host application that loads each slice and renders it into the page. Spotify later moved its desktop client away from iframe composition on performance grounds. Useful reminder: adopting the pattern is a decision you can also reverse.
SoundCloud: a European music sharing and audio distribution platform serving a consistent experience across web, mobile and embedded players.

Treat that list as evidence the pattern scales, not as a reason to adopt it. Every company on it runs dozens of frontend teams. That is the condition the architecture is answering.

A brief overview of the micro frontend architecture

The goal of a micro frontend is to give you what microservices gave the back end, without the drawbacks that come with a big frontend monolith.

To see why it works, we need to be precise about two things: what microservices actually changed on the server side, and what stayed stubbornly unchanged on the client side. We saw both sides of that line rebuilding Eurofound's front-end and back-end integration, where a modular back end still had to meet a single front end.

Architectural evolution from a monolithic application to a micro frontend for your business.

What is microservices architecture?

Microservice architecture is a design pattern in backend development. Where a monolithic architecture ships as one unit, microservices are several independently deployable components, separated by business domains and connected by APIs.

What that buys a business is narrower than the usual list of adjectives suggests, and worth stating plainly:

A change is deployable without a queue. One service goes to production without every other service being ready, so the number of teams waiting on a release window drops to zero.
Capacity is bought where it is consumed. You scale the two services under load rather than the whole application, which is what makes the infrastructure bill track usage instead of peak.
A failure is contained. One service falling over degrades one capability instead of taking the product down, so the blast radius of an incident matches the size of the change that caused it.
Technology choices stop being permanent. Each service can use what fits it, so replacing one does not require a platform-wide decision.

Those four are also, precisely, the properties a frontend monolith does not have, however modern the back end behind it is. Our guide to software architecture sets out where the trade sits at different team sizes.

Why is a frontend monolith a bad fit for microservices?

A frontend monolith is the client side of a web application built from a single codebase. Plenty of products still run one, including products whose back end is fully decomposed. The server side is modular; the frontend stays whole.

For one or two teams, that is the right shape. Truth be told, it is usually the right shape for longer than people expect. The symptoms show up as the number of teams touching that codebase grows, and they are specific enough to check for:

Release contention. Every team ships on the same pipeline, so a release goes out when the slowest change in it is ready. One team's failing test holds everyone else's finished work.
Queue length in front of a change. A small frontend change waits for review from people who own other parts of the codebase, then waits for the next release train. The work is hours. The lead time is weeks.
Blast radius. A regression anywhere in a shared bundle can take down every feature in it, so each deployment carries the risk of the whole frontend rather than the risk of one change.
Coupling that outlives the decision. Framework and dependency versions are shared, so an upgrade becomes a whole-product project, gets deferred, and eventually becomes a migration — the slow accrual of technical debt nobody has time to pay down.

A frontend monolith, in other words, restricts the independent delivery you adopted microservices to get. That is the gap micro frontends close. And it is worth being blunt about the nature of that gap: it is organisational. If the delay lives in review culture or in a change board rather than in the codebase, splitting the codebase will not move it.

Independent deployment only helps if the delivery process behind it is disciplined, which is where the best agile practices earn their place.

Illustration of a woman with planning cards next to text about 18 best agile practices for software development.

Why use a micro frontend?

With a micro frontend, companies can:

Provide a consistent user experience across devices and third-party platforms. Every slice is composed into the same shell, so navigation, session and design tokens, the shared values for colour, type and spacing, behave the same wherever the user meets them. The mechanism is the shell and the design system, not the split itself, which is why both need an owner from day one.
Shorten the queue in front of a frontend change. A team that owns a slice releases it without waiting for a shared release train, so a change goes out when it is ready rather than when the train leaves. The saving shows up in cycle time, not in engineering headcount.
Scale the product surface without a rewrite. New capability arrives as a new slice instead of a change to an existing codebase, so what the product can carry stops being limited by what one frontend codebase can hold.

Cross-functional end-to-end teams managing separate product features in a micro frontend architecture.

This suits teams that already run independent delivery on the back end. The gains are real, and every one of them has a cost attached in the next section.

What a micro frontend gains you

The published benefit lists for this architecture run long. In delivery they collapse into four gains, each with the mechanism behind it and the condition it depends on.

Ownership that runs end to end. A team takes a slice from ideation through release to production support, and that is what removes the coordination overhead, not the code split on its own. Several teams then work the same product in parallel with far less negotiation than a shared codebase demands. The condition is real autonomy: a team that still needs sign-off elsewhere gains nothing.
Deployment independence, and the release cadence that follows. Each slice has its own pipeline, so a feature reaches production without every other team being ready, and a rollback touches one slice instead of the whole frontend. This is the gain that pays for the architecture. It is also the one to measure.
Codebases small enough to hold in your head. A monolithic frontend grows unstructured because no single team can see all of it. Keeping each slice inside one team's comprehension is what produces the cleaner code and the easier testing, both consequences of size rather than properties of the pattern. The corollary is that testing the assembled product gets harder, which is in the next list.
Per-slice technology choices, including the freedom to move off one. Different slices can run different frameworks and versions, so no part of the product is locked to a legacy choice for the lifetime of the app, and an upgrade can be proven on one slice before it spreads. Bundle size cuts both ways here: the browser downloads only the code a page needs, but if every slice ships its own copy of the framework, the total payload can exceed the monolith's. Manage shared dependencies deliberately.

What a micro frontend costs you

The costs are those same four properties read from the other side. None is a reason to avoid the architecture. All of them need an owner before you start.

The assembled product needs testing as a product. Each slice tests cleanly in isolation. Proving that they work together, across independent pipelines, needs an end-to-end suite and somebody accountable for it, or integration problems surface in production.
More moving parts in delivery. A distributed frontend means more pipelines, more dependencies between slices, and more ways to assemble the whole thing wrongly. As the number of slices grows, so does the effort of keeping the dependency picture clear enough to deploy safely.
Consistency stops being automatic. Mixed frameworks across slices can leave you with an uneven stack, uneven performance and an interface that drifts visibly from one part of the product to the next. Back to the shopping centre: without shared signage and a lettings policy, you get a row of shops rather than a destination.
A standing platform cost. The shell, the composition layer, the design system and the end-to-end suite all have to be built and then maintained, alongside the management capacity to coordinate several teams. That cost starts before the first slice ships, and it does not stop after launch.

Micro frontend vs monolith: a side-by-side

The two architectures answer different problems. This is the trade at a glance — read it as "which constraint are you actually under?", not "which is better".

Dimension	Monolithic frontend	Micro frontend
Codebase	One shared repository everyone changes	Several independently owned slices
Deployment	One shared pipeline / release train	Per-slice pipeline, deploy on demand
Team fit	One or two teams	Three or four-plus autonomous teams
Release cadence	Gated by the slowest change in the batch	Each slice ships when it is ready
Blast radius	A regression can take down the whole frontend	Contained to one slice
Technology	Shared framework and versions; an upgrade is a whole-product project	Per-slice choice; an upgrade is proven on one slice first
Bundle size	One payload, no duplication	Only the code a page needs — but risk of duplicated framework copies
Testing	Simpler end-to-end: one unit to test	Slices test in isolation; the assembled product needs its own e2e suite
Standing platform cost	None beyond the application itself	Shell + composition + design system + e2e suite (≈ one engineer plus a design-system owner)
Best when	Release contention is not your bottleneck	Several autonomous teams queue to deploy the same codebase

What does a micro frontend cost, and when does it pay back?

The commercial case is a trade between coordination cost and delivery speed, and it only clears at a certain scale. The figures below are indicative rather than universal. The shape of the trade matters more than the numbers.

The team-size threshold. Below three or four autonomous frontend teams, micro frontends generally lose money: the platform work and cross-team coordination cost more than the release contention they remove. A single team gets a distributed system with none of the organisational benefit.
Platform and coordination overhead. Expect a standing cost for the shell, the shared design system, the composition layer and the end-to-end test suite. On the engagements we see, that is roughly one engineer's continuous capacity plus a design system owner, and it does not go away after launch.
Where the return shows up. The gain is deployment independence, so measure it in cycle time and release frequency rather than headcount saved. Teams moving off a shared fortnightly train onto their own pipeline see the largest change. Teams already releasing daily see very little.
Sequencing. Migrating an existing monolith slice by slice, behind the shell, is the low-risk path, and it takes quarters rather than sprints. A rewrite in one step carries the risk profile of any rewrite.
The failure modes that force a rollback. Three recur: duplicated framework payloads that make the page slower than the monolith was; a design system nobody owns, so the UI drifts visibly between slices; and version skew, slices running incompatible versions of a shared dependency or contract, which typically only appears once they are deployed together in production. Each one is a governance problem rather than a technical one, which is why the readiness check below is about the organisation.

When to use micro frontends

Micro frontend architecture has real advantages, and it is not a one-size-fits-all solution. Not every web application suits this style, and the deciding factors are organisational as much as technical.

The three-gate readiness check

Before adopting micro frontends, we put a candidate through three gates. Fail any one of them and the monolith is still the better answer, with that gate as the work to do first.

Team count and autonomy. Are there at least three or four frontend teams, each able to release without another team's approval? If release decisions still route through one lead or one change board, the architecture removes a bottleneck that is not where the delay is.
Domain separability. Does the product divide into self-contained verticals with clear boundaries, so a slice can own its data and its UI end to end? A multi-module enterprise resource planning system (finances, CRM, HR, inventory) separates cleanly. A single dense workflow that every team touches does not.
Deployment maturity. Can each team deploy on demand behind feature flags, the switches that let a change ship turned off and be enabled later, with monitoring and a rollback path it controls? Micro frontends multiply the number of independent deployments, so a delivery process that is fragile at one pipeline will be worse at eight.

Two supporting conditions matter too. Separate technology stacks for different modules should be a genuine requirement rather than a preference, and the budget has to carry the standing platform cost set out above.

If you are unsure whether micro frontends suit your project, walk the three gates through with someone who has run the migration before. In the end it depends on the specifics of your business plan, not on the architecture's merits in the abstract.

What holds the slices together: routing, state and authentication

Splitting the frontend is the easy half. What decides whether the result holds together sits in four concerns no single slice owns, and each needs a decision before the first migration rather than after it.

Routing. The shell owns the top-level routes and hands a matching URL to the slice that owns it; the slice owns everything below that path. Get this boundary wrong and you end up with two competing routers, plus a back button that behaves differently in different parts of the product.
Shared state and session. Keep the shared surface as small as it will go: who the user is, what they are entitled to, which tenant or locale they are in. Everything else belongs to the slice that owns the data. Slices that read each other's internal state quietly rebuild the coupling you split things up to remove.
Authentication. Authenticate once in the shell, then pass a token the slices verify against the API. Slices that each carry their own login flow produce the seams users notice first.
Design system governance. Shared components need a version policy, a deprecation path and an owner with the authority to say no. Without that, each slice forks the component it needs and the interface drifts inside a quarter.

Utility components that manage state or talk to the application environment, rather than rendering anything, can be loaded on demand like any other slice. They usually carry no UI, which makes them easy to overlook when you decide who owns what.

How to implement a micro frontend?

You can integrate micro frontends in two ways: at build time, or at run time.

Build-time integration: slices installed as libraries

The container installs each slice as a library, much as you would install a package from npm, the Node.js package registry. This is how most code is written today, and it is the simplest thing that works.

The drawbacks are why most teams move past it. Multiple versions of shared libraries have to be kept in sync, and build issues follow when they are not. Combining several technologies is difficult. The final package carries every dependency, so it is large. And because any change to a dependency means rebuilding and redeploying the container, the container and all its slices stay tightly coupled. Which is the coupling the architecture exists to remove.

Run-time integration: server, edge and client composition

Run-time integration composes the page from independently deployed slices while it is being served, or after it loads, so a slice can be released without rebuilding the container. Compositions come in three types:

Server-side composition. The back end determines which slice to load and when, with URLs deciding how the server routes requests.
Edge-side composition. The orchestration happens on the content delivery network (CDN), the distributed network of servers between your origin and the user. The edge assembles pages and serves static material, taking on work the origin server would otherwise do.
Client-side composition. A container in the browser decides which version of each slice to load, because the container and the slices deploy separately, and requests each slice as it is needed. This is the mainstream option, and the usual tooling for it is Module Federation — now at version 2 and available in Webpack 5 and Rspack — which loads slices from remote entry points at run time. Next.js is the awkward exception worth calling out: the community @module-federation/nextjs-mf plugin only ever supported the older Pages Router, never the default App Router, and its maintainers have flagged it for end-of-life around the end of 2026. For App Router projects, Vercel's first-party @vercel/microfrontends package — built on a Multi-Zones model rather than runtime chunk-stitching — is now the supported path. single-spa remains the main alternative where slices are built with different frameworks.

Frequently asked questions

What is a micro frontend in simple terms?

A micro frontend is one slice of a web application's user interface, built and deployed on its own by the team that owns it. Instead of a single frontend codebase everybody changes, the page is assembled from several independent slices at build time or in the browser. Each team ships without waiting for the others.

Micro frontend vs monolith: which should we choose?

Choose the monolith unless release contention is your actual bottleneck. A single frontend codebase is simpler to build, test and reason about, and it stays the right answer for one or two teams. Micro frontends earn their cost once several autonomous teams are queueing to deploy the same codebase, and the queue, not the code, is what slows you down.

How much does a micro frontend cost to run?

Beyond the teams themselves, budget for a standing platform cost: the shell, the composition layer, a shared design system and an end-to-end test suite. On the engagements we see, that is around one engineer's continuous capacity plus a design system owner, and it persists after launch. The saving that offsets it is cycle time, not headcount.

How many teams do you need before micro frontends pay off?

Three or four autonomous frontend teams is the usual threshold, and autonomy matters more than the count. If every release still routes through one lead or one change board, splitting the frontend removes a bottleneck that was never the constraint. One team adopting micro frontends gets the operational cost of a distributed system with none of the organisational benefit.

What are the biggest micro frontend mistakes?

Three recur. Shipping a copy of the framework with every slice, so the page ends up slower than the monolith it replaced. Leaving the design system unowned, so the interface visibly drifts between slices. And letting versions skew across independently deployed slices, which only shows up in production. All three are governance failures rather than technical ones.

Do micro frontends slow down page load?

They can go either way. Splitting the application means the browser downloads only the code a page needs, which helps. Duplicated dependencies across slices push in the opposite direction and can leave the total payload larger than before. Which effect wins depends on whether shared dependencies are managed deliberately, so measure page speed per release rather than assuming it.

Can you migrate to micro frontends gradually?

Yes, and it is the lower-risk route. Put a shell in front of the existing monolith, carve out one vertical with clear boundaries, and give it to a team to own end to end. Each subsequent slice follows the same path. Expect the migration to run over quarters rather than sprints, and keep the option of stopping partway.

Conclusion

Micro frontends give the frontend what microservices gave the back end, independent delivery, by trading coordination cost for delivery speed. That trade only clears at scale: the platform carries a standing cost, and the failure modes are organisational rather than technical. So run the three gates first: team count and autonomy, domain separability, deployment maturity. If one fails, fixing it is the higher-value work, and the monolith remains the better answer for now.

We have built, maintained and migrated both micro frontends and monoliths, and we are happy to walk your estate through the three gates, including when the answer is to stay put. Get in touch and we will take a look.

Alexandra Mendes

Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.

André Santos

Your everyday web developer who likes to hide in the backend. Javascript and Ruby are my jam. I still fumble with Docker and my builds break quite often.

‍