Micro-Frontends in 2026: The Complete Engineer's Guide to Module Federation, Rspack, and Shared State

A micro-frontend architecture consists of three layers:

1. Shell / Host App: The main application container that orchestrates routing and renders remote micro-frontends inside designated slots.
2. Remote Apps (Remotes): Independently deployable frontend applications that expose components or pages via Module Federation.
3. Shared Library Layer: A controlled set of packages (React, design system tokens, auth utilities) that are shared across remotes to prevent version conflicts and code duplication.

The critical insight here is that remotes should be completely self-contained. They should start standalone, have their own CI/CD pipelines, and own their backend data fetching. The shell should only know where to mount a remote, not how it works internally.

Setting Up Rspack with Module Federation v2

Rspack's zero-config Module Federation support makes the setup dramatically easier than Webpack. Here is a production-quality host configuration:

// rspack.config.ts — Host Application
import { defineConfig } from '@rspack/cli';
import { ModuleFederationPlugin } from '@module-federation/enhanced/rspack';

export default defineConfig({
  entry: './src/index.tsx',
  output: { publicPath: 'auto' },
  plugins: [
    new ModuleFederationPlugin({
      name: 'host_shell',
      remotes: {
        // Dynamic remote — URL resolved at runtime from a config service
        dashboard: 'dashboard@[dashboardUrl]/mf-manifest.json',
        payments: 'payments@[paymentsUrl]/mf-manifest.json',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.3.0', eager: true },
        'react-dom': { singleton: true, requiredVersion: '^18.3.0', eager: true },
        '@company/design-system': { singleton: true, eager: false },
      },
    }),
  ],
});

The key difference from the older Webpack approach is the mf-manifest.json pattern. Instead of hardcoding a remoteEntry.js URL, each remote publishes a typed manifest that allows the host to perform runtime version negotiation — ensuring you never load an incompatible remote version in production.

Lazy Loading and Error Boundary Isolation Per Remote

One of the most painful failure modes in micro-frontends is a runtime error in one remote crashing the entire shell application. The solution is to wrap every dynamic remote import in a dedicated React Error Boundary combined with Suspense:

import React, { Suspense, lazy } from 'react';
import { ErrorBoundary } from 'react-error-boundary';

// Lazily import from remote
const DashboardApp = lazy(() => import('dashboard/DashboardRoot'));

function DashboardSlot() {
  return (
    <ErrorBoundary
      fallbackRender={({ error }) => (
        <div className="remote-error-state">
          <h3>Dashboard temporarily unavailable</h3>
          <p>{error.message}</p>
        </div>
      )}
    >
      <Suspense fallback={<DashboardSkeleton />}>
        <DashboardApp />
      </Suspense>
    </ErrorBoundary>
  );
}

This pattern guarantees that if the dashboard remote fails to load (network error, deployment rollback, version conflict), the rest of the shell application — including the payments module, navbar, and account settings — remains fully functional.

The 3 Proven Patterns for Cross-Remote State Sharing

The most debated topic in micro-frontend architecture is state sharing. The wrong answer (and a red flag in interviews) is to create a monolithic shared Redux or Zustand store. This creates tight coupling that defeats the independence principle. Here are the three patterns that actually work in production:

Pattern 1: Custom DOM Events (Best for Loose Notifications)

When one remote needs to notify others about a global event (language change, user logout, cart update), a custom DOM event is the simplest, most decoupled approach:

// In payments remote — dispatch an event when purchase is complete
window.dispatchEvent(new CustomEvent('purchase:complete', {
  detail: { orderId: 'ORD-9821', amount: 4999 }
}));

// In dashboard remote — listen for the event
window.addEventListener('purchase:complete', (e) => {
  refreshActivityFeed(e.detail.orderId);
});

Pattern 2: Shared Auth Context via Session Storage (Best for User Identity)

Authentication state must be consistent across all remotes. The cleanest pattern is to have the shell write the JWT and decoded user claims to sessionStorage on login. Each remote reads from this on mount and registers a listener for logout events:

// Shell — after successful login
sessionStorage.setItem('auth_token', jwt);
sessionStorage.setItem('user_claims', JSON.stringify(claims));

// Remote — read on initialization
const token = sessionStorage.getItem('auth_token');
const claims = JSON.parse(sessionStorage.getItem('user_claims') || '{}');

Pattern 3: An RxJS Event Bus (Best for Complex, Real-Time Streams)

For applications with complex bidirectional state flows (think Figma-like collaborative tools), an RxJS Subject shared via the Module Federation shared layer provides a type-safe, reactive event bus with replay buffers and filtering support.

CI/CD and Independent Deployment Strategy

The true power of micro-frontends is realized only when each remote has its own deployment pipeline. A monorepo with Turborepo or Nx makes this manageable:

• Per-remote pipeline: Each remote's CI only triggers when files within its directory change.
• Manifest Registry: After a successful build, each remote pushes its new mf-manifest.json to a central manifest registry (an S3 bucket or Cloudflare KV store) keyed by environment (prod, staging).
• Shell reads manifests at runtime: The shell fetches the latest manifest URLs from the registry on startup, ensuring it always loads the latest deployed version without a shell re-deploy.

Performance Benchmarks: Rspack vs Webpack in Production

In real-world migration case studies from teams at scale, the improvements from switching to Rspack are dramatic. A codebase with 8 remote apps previously taking 4.5 minutes for a full production build dropped to under 28 seconds. Hot Module Replacement in development went from 800ms average to under 80ms. These aren't micro-optimizations — they directly translate to faster developer feedback loops and faster deployment pipelines.

Common Micro-Frontend Interview Mistakes (and How to Avoid Them)

When asked to design a micro-frontend system in an interview, avoid these pitfalls:

• ❌ Proposing a single shared Redux store across all remotes.
• ❌ Not mentioning Error Boundaries — this signals inexperience with production failure modes.
• ❌ Tightly coupling remotes to a specific shell version via hardcoded remoteEntry.js URLs.
• ✅ DO mention: version negotiation via manifests, error isolation, event-driven state sharing, and independent CI/CD.