What is micro-frontend architecture?

Micro-frontend architecture is an approach to front-end development where a web application is decomposed into smaller, semi-independent 'micro-apps.' Each micro-app is owned by a separate team, uses its own tech stack if needed, and can be developed, tested, and deployed independently. The concept extends microservices principles to the browser, enabling large organisations to scale their front-end engineering without creating a monolithic codebase.

When should you NOT use micro-frontends?

Micro-frontends introduce operational complexity — separate builds, deployment pipelines, shared dependency management, and cross-app communication. If your application is small, your team is fewer than five developers, or your release cadence is already fast, a well-structured monolith or a modular single-page application is almost always simpler and more cost-effective. Micro-frontends shine when multiple autonomous teams need to ship features to the same product without stepping on each other's toes.

Micro-Frontend Architecture: How to Split Your Web App Effectively

Why Monolithic Front-Ends Hit a Wall

Modern web applications grow fast. What begins as a tidy React or Vue project with ten components can balloon into hundreds of modules, thousands of tests, and a build that takes eight minutes on a good day. Teams start queuing pull requests, release trains slow down, and a CSS change in the checkout flow accidentally breaks the product catalog.

Sound familiar? You are not alone. A 2023 State of JS survey showed that 62 % of front-end developers working on enterprise apps reported build-time frustration as a top productivity killer. The root cause is almost always the same: a monolithic front-end that has outgrown the team structure around it.

This is exactly the problem micro-frontend architecture was designed to solve.

What Are Micro-Frontends, Exactly?

Micro-frontends apply the idea behind microservices — small, autonomous, independently deployable units — to the user interface layer. Instead of one giant SPA owned by everybody (and therefore by nobody), the application is split into vertical slices, each covering a business domain:

Team Catalog owns the product listing and search pages.
Team Checkout owns the cart, payment, and order confirmation.
Team Account owns profile, addresses, and order history.

Each slice can be built with a different framework version — or even a different framework altogether — though in practice most organisations standardise to reduce bundle overhead.

The Core Principles

Technology agnosticism – Each micro-frontend chooses its own stack (within guardrails).
Isolated codebases – No shared state at the code level; communication happens through well-defined APIs or events.
Independent deployability – Team Checkout ships on Tuesday without waiting for Team Catalog.
Resilient UX – If one micro-frontend fails to load, the rest of the page still works.

Composition Strategies: Choosing the Right One

The biggest architectural decision you will make is how and where the micro-frontends are stitched together. There are three main approaches, each with distinct trade-offs.

Strategy	Where composition happens	Latency impact	Complexity	Best for
Build-time integration	CI/CD pipeline	None at runtime	Low	Small teams, shared release cadence
Server-side integration	Edge / origin server	Low (HTML streaming)	Medium	Content-heavy sites, SEO-critical pages
Client-side (runtime) integration	Browser	Medium–High	High	Large orgs, independent deploy cycles

Build-Time Integration

Micro-frontends are published as npm packages. A shell application imports them at build time and produces a single deployable bundle.

// package.json of the shell app
{
  "dependencies": {
    "@acme/catalog-mfe": "^2.4.0",
    "@acme/checkout-mfe": "^1.7.3",
    "@acme/account-mfe": "^3.1.0"
  }
}

Pros: Simple mental model, one deployment artefact, optimal bundle size with tree-shaking.

Cons: Coupling at release time — a new version of checkout-mfe still requires the shell to rebuild and redeploy. This diminishes the key benefit of independent deployability.

Server-Side Integration

Fragments are assembled on the server before HTML reaches the browser. Technologies include SSI (Server Side Includes), ESI (Edge Side Includes), and frameworks like Podium or Piral.

At Lueur Externe, our AWS Solutions Architect team frequently leverages Lambda@Edge with CloudFront to compose micro-frontend fragments at the CDN layer, keeping Time-to-First-Byte under 120 ms even for highly dynamic pages.

<!-- Simplified ESI example at the edge -->
<html>
<body>
  <header>
    <esi:include src="/mfe/header" />
  </header>
  <main>
    <esi:include src="/mfe/catalog" />
  </main>
  <footer>
    <esi:include src="/mfe/footer" />
  </footer>
</body>
</html>

Pros: Great for SEO (fully rendered HTML), fast perceived load, graceful degradation.

Cons: Requires edge/CDN infrastructure, more complex caching rules, limited interactivity without client-side hydration.

Client-Side (Runtime) Integration

This is the most popular approach in large-scale SPAs. The shell app loads micro-frontends on-demand in the browser using one of these techniques:

Webpack Module Federation – Share modules at runtime between separately built bundles.
Single-SPA – An orchestration framework that mounts and unmounts micro-apps based on URL routes.
Web Components – Each micro-frontend exposes a custom element (<checkout-app />).
iFrames – The old-school (but battle-tested) sandboxing mechanism.

Module Federation in Action

Webpack 5’s Module Federation has become the de facto standard for runtime micro-frontend integration. Here is a minimal configuration for a host (shell) and a remote (catalog):

// webpack.config.js — Catalog remote
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalog',
      filename: 'remoteEntry.js',
      exposes: {
        './ProductList': './src/components/ProductList',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.2.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
      },
    }),
  ],
};

// webpack.config.js — Shell host
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        catalog: 'catalog@https://cdn.example.com/catalog/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.2.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
      },
    }),
  ],
};

In the shell’s React code, loading the remote component is as simple as:

const ProductList = React.lazy(() => import('catalog/ProductList'));

function App() {
  return (
    <React.Suspense fallback={<Spinner />}>
      <ProductList />
    </React.Suspense>
  );
}

Pros: True independent deployment, lazy loading per route, framework-agnostic with the right wrapper.

Cons: Larger total payload if shared dependencies are not managed carefully, runtime errors are harder to debug across boundaries.

Handling Cross-Cutting Concerns

Splitting the UI is only half the battle. The other half is ensuring the seams between micro-frontends do not leak complexity into the user experience.

Routing

A top-level router in the shell typically owns the URL space and delegates to each micro-frontend:

/products/* → Catalog MFE
/cart/* → Checkout MFE
/account/* → Account MFE

Each micro-frontend then manages its own sub-routing internally. Libraries like single-spa handle mount/unmount lifecycle hooks automatically based on URL patterns.

Shared State and Communication

Golden rule: micro-frontends should share as little state as possible. When they absolutely must communicate, prefer one of these patterns:

Custom browser events – Lightweight and framework-agnostic.
A shared event bus – A tiny pub/sub library injected by the shell.
URL / query parameters – The simplest contract; great for passing IDs between domains.
A shared auth token stored in an HttpOnly cookie — avoids duplicating login flows.

// Publishing an event from Catalog MFE
window.dispatchEvent(
  new CustomEvent('product:addedToCart', {
    detail: { sku: 'ABC-123', qty: 1 },
  })
);

// Listening in Checkout MFE
window.addEventListener('product:addedToCart', (e) => {
  cartStore.add(e.detail.sku, e.detail.qty);
});

Design System Consistency

Nothing kills the micro-frontend promise faster than five slightly different shades of blue across the app. A shared design system — published as a versioned component library — is essential:

Publish tokens (colours, spacing, typography) as CSS custom properties.
Publish UI primitives (buttons, inputs, modals) as framework-agnostic Web Components or as a React/Vue library.
Enforce visual regression testing in CI with tools like Chromatic or Percy.

Performance Pitfalls (and How to Avoid Them)

Micro-frontends can easily bloat your page if you are not careful. Here are the most common pitfalls with measurable impacts:

Duplicate frameworks – Loading React twice adds ~42 kB gzipped. Always mark shared libs as singleton in Module Federation.
Waterfall loading – The shell loads → then fetches remote entry → then fetches the chunk. Use <link rel="preload"> for critical remote entries.
CSS conflicts – Global styles from one MFE leak into another. Scope styles with CSS Modules, Shadow DOM, or naming conventions like BEM with a team prefix.
Too many micro-frontends on one page – Each additional MFE adds HTTP requests and JavaScript evaluation time. Aim for 2–4 MFEs per route, not 15.

A benchmark by the Thoughtworks Technology Radar team found that a well-optimised micro-frontend setup adds roughly 50–150 ms to First Contentful Paint compared to a monolith — an acceptable trade-off for organisations with 5+ autonomous teams.

Real-World Adoption: Who Uses Micro-Frontends?

IKEA rebuilt its e-commerce platform with micro-frontends, enabling over 30 teams to ship features to ikea.com independently.
Spotify uses an internal framework called Backstage to manage hundreds of micro-frontends across desktop and web.
Zalando pioneered the approach with Project Mosaic, composing pages from fragments served by different teams.
DAZN (sports streaming) migrated from a monolithic SPA to micro-frontends and reduced deployment lead time from two weeks to under one hour.

These are not small hobby projects. These are high-traffic, revenue-critical platforms. The pattern works — but only when implemented with discipline.

A Decision Framework: Is It Right for You?

Before jumping in, answer these five questions:

Do you have more than one autonomous front-end team? If not, a well-structured monolith is simpler.
Do teams block each other at deploy time? If releases queue up, micro-frontends remove that bottleneck.
Is your application large enough? For apps under ~50 routes, the overhead may not be worth it.
Can you invest in platform engineering? Micro-frontends need CI/CD pipelines, a shared design system, and observability tooling.
Is your organisation ready for distributed ownership? The architecture mirrors the team structure (Conway’s Law). If governance is unclear, the architecture will be too.

If you answered yes to at least three of these, micro-frontends deserve a serious proof of concept.

Step-by-Step Migration Path

Migrating a monolith to micro-frontends does not happen overnight. Here is a pragmatic roadmap:

Phase 1 — Strangler Fig (Months 1–3)

Pick one low-risk, high-value slice of the app (e.g., the account settings page). Build it as a standalone micro-frontend and embed it into the existing monolith via an iframe or a client-side mount point. This proves the tooling works without risking the checkout flow.

Phase 2 — Shell Extraction (Months 3–6)

Build a lightweight shell application that owns the top-level layout (header, navigation, footer) and routing. Gradually move routes from the monolith to dedicated micro-frontends.

Phase 3 — Full Decomposition (Months 6–12)

Migrate remaining routes. Establish governance: a shared ADR (Architecture Decision Record) repo, a design-system contribution guide, and automated performance budgets in CI.

At Lueur Externe, we have guided several e-commerce and SaaS clients through this exact migration path — leveraging our deep Prestashop and WordPress expertise alongside modern JavaScript architectures to ensure zero downtime and measurable performance gains at every phase.

Common Mistakes to Watch Out For

Nano-frontends – Splitting too granularly (one MFE per button) creates more problems than it solves. Align boundaries with business domains, not UI elements.
Ignoring the shell – The shell is a product, not an afterthought. Under-investing in its routing, error handling, and loading states leads to a fragile user experience.
Skipping contracts – Without versioned interface contracts between MFEs, a breaking change in one team’s exposed component cascades silently.
No shared observability – Distributed tracing, centralised logging, and real-user monitoring (RUM) must span all micro-frontends. Tools like Datadog, Sentry, or OpenTelemetry are non-negotiable.

The Future: Server Components and Beyond

React Server Components (RSC), Astro Islands, and Qwik’s resumability model are blurring the line between server-side and client-side composition. These emerging patterns share a core idea with micro-frontends: render only what the user needs, when they need it.

Expect Module Federation to evolve (Rspack and Vite already have early support), and expect meta-frameworks like Next.js and Nuxt to offer first-class micro-frontend primitives within the next two years.

Conclusion: Architect for Autonomy, Not Just Modularity

Micro-frontend architecture is not a silver bullet. It is a scaling strategy — one that trades a degree of runtime simplicity for organisational velocity. When implemented thoughtfully, it lets multiple teams innovate in parallel, deploy with confidence, and maintain a cohesive user experience across a sprawling application.

The keys to success are clear domain boundaries, a robust shell, shared design tokens, and disciplined dependency management. Get those right, and your front-end will scale as smoothly as your backend microservices already do.

Ready to decompose your monolithic front-end — or need an expert audit of your current architecture? The team at Lueur Externe combines 20+ years of web engineering experience with certified AWS and e-commerce expertise to help you design, build, and ship micro-frontend platforms that perform at scale. Get in touch today and let’s architect your next move together.