Microfrontends & Module Federation — System Design Interview Guide

The Problem Microfrontends Solve

In large organisations, a single frontend monolith becomes a bottleneck: 20 teams all commit to the same repo, CI takes 30 minutes, one bad deploy blocks everyone. Microfrontends decouple teams so they can build, test, and deploy independently — exactly like microservices did for backends.

Four Integration Approaches

1. Webpack Module Federation (Most Common)

Webpack 5's built-in mechanism for sharing code at runtime across separate builds. One app exposes components; another app consumes them — no npm publishing required. The host app downloads the remote bundle lazily when needed.

// Remote (Team B — Cart MFE) — webpack.config.js
new ModuleFederationPlugin({
  name: 'cart',
  filename: 'remoteEntry.js',
  exposes: {
    './CartWidget': './src/CartWidget',
  },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
})

// Host (Shell App) — webpack.config.js
new ModuleFederationPlugin({
  name: 'shell',
  remotes: {
    cart: 'cart@https://cart.example.com/remoteEntry.js',
  },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
})

// Shell — usage at runtime
const CartWidget = React.lazy(() => import('cart/CartWidget'));
// ↑ loads from cart.example.com at runtime, not bundled into shell

Key insight: shared: { react: { singleton: true } } ensures both apps use the same React instance — critical to avoid the "two Reacts" bug.

2. Single-SPA

A JavaScript framework for orchestrating multiple micro-apps. Each app registers with a root-config that controls when to mount/unmount them based on the URL. Unlike Module Federation, Single-SPA is framework-agnostic — you can mix React, Vue, and Angular in the same shell.

// Root config — registers microfrontends
registerApplication({
  name: '@company/navbar',
  app: () => import('@company/navbar'),
  activeWhen: ['/'], // always active
});
registerApplication({
  name: '@company/products',
  app: () => import('@company/products'),
  activeWhen: ['/products'],
});

3. iframes

Strongest isolation — each microfrontend is sandboxed in its own browsing context. Zero risk of CSS or JS conflicts. But terrible UX: poor accessibility, fixed height issues, hard to share state, navigation breaks browser history.

4. Web Components

Native custom elements that can encapsulate framework-specific UI. A React microfrontend wrapped in a Web Component can be dropped into any HTML page. Good for widgets and embeds, not great for complex composed applications.

Shared State — The Hard Problem

Microfrontends that need shared state (user session, cart count, notifications) should communicate through events not direct references. The shell owns global state; MFEs fire custom events or use a lightweight event bus. Direct imports between MFEs create hidden coupling and break independent deployability.

// Event bus pattern for cross-MFE communication
window.dispatchEvent(new CustomEvent('cart:updated', { detail: { count: 3 } }));

// Another MFE listens
window.addEventListener('cart:updated', (e) => setCount(e.detail.count));

When NOT to Use Microfrontends

Small teams and small apps do not benefit — you get all the operational complexity with none of the team-scaling benefit. The overhead of separate repos, CI pipelines, versioning, and bundle size management is only justified when multiple independent teams work on the same product simultaneously.