Micro Frontend Architecture at Scale

I've led micro frontend migrations at two large product companies. Both were complex, both had painful moments, and both taught me things I wish I'd known going in.

This post covers the real challenges: module federation config, shared state pitfalls, team coordination, and what I'd do differently.

Why Micro Frontends?

At organization with a massive monolithic React app. 40+ engineers touching the same codebase meant slow builds (14 min), risky deployments, and feature teams blocked by each other constantly.

The goal was simple: let each team own, build, and deploy their slice of the UI independently.

Module Federation — The Setup That Actually Works

// Host app webpack.config.js
new ModuleFederationPlugin({
  name: 'host',
  remotes: {
    taxWizard: 'taxWizard@https://cdn.xyz.com/tax-wizard/remoteEntry.js',
    dashboard:  'dashboard@https://cdn.xyz.com/dashboard/remoteEntry.js',
  },
  shared: {
    react: { singleton: true, requiredVersion: '^18.0.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
    'react-redux': { singleton: true },
  },
})

The Shared State Problem

This is where most teams get it wrong. You have two options:

Option A — Shared Redux Store (what we tried first)

We exposed a shared Redux store from the host. It worked initially but created tight coupling — MFEs had to know about each other's state shape, and a bad action in one MFE could corrupt another's state.

Option B — Event Bus + Local State (what we switched to)

We built a lightweight event bus on window.__AK_BUS__ for cross-MFE communication. Each MFE owns its own local state and only publishes/subscribes to events it cares about:

// Shared event bus (host initialises this)
window.__AK_BUS__ = {
  emit: (event, payload) => window.dispatchEvent(
    new CustomEvent(event, { detail: payload })
  ),
  on: (event, cb) => window.addEventListener(event, e => cb(e.detail)),
  off: (event, cb) => window.removeEventListener(event, cb),
}

// In a remote MFE:
window.__AK_BUS__.emit('user:authenticated', { userId: '123' });

// In another remote:
window.__AK_BUS__.on('user:authenticated', ({ userId }) => {
  loadUserDashboard(userId);
});

Deployment Independence

The whole point of MFEs is independent deployment. Here's how we achieved it:

• Each MFE has its own CI/CD pipeline (GitHub Actions → S3 + CloudFront)
• remoteEntry.js is versioned and URL-based — host always fetches the latest from CDN
• We used a feature flag service to control which version of a remote the host loads in production
• Canary deployments: route 5% of traffic to new remote, monitor errors, then full rollout

Team Ownership Model

Results After Migration

• Build time: 14 min → 2.5 min per MFE (82% faster)
• Deployment frequency: weekly → daily per team
• Incident blast radius: reduced — a broken MFE no longer takes down the whole app
• New developer onboarding: 2 weeks → 3 days (smaller codebase per team)