Micro Frontend Architecture: Vertical vs Horizontal for 10M+ Users

Micro frontends split a monolithic frontend into independently deployable domain-owned UI slices. Teams ship faster using vertical decomposition (by domain) or horizontal decomposition (by layer). The right architecture depends on one question: does your bottleneck live in delivery speed or UI consistency?

The Insight AI Won’t Give You

Most engineers treat micro frontends as a build-time problem. It isn’t.

Micro frontends are an organizational topology problem first.

Conway’s Law dictates your architecture. If your teams are siloed by function (design, API, infra), your frontend will be too. And it will hurt. I have seen $10M platforms collapse under horizontal layer ownership because nobody owned the experience end-to-end.

The contrarian take: Start vertical. Add horizontal boundaries only where UI consistency becomes the actual bottleneck and not where it feels like it might become one.

This is the lesson from rebuilding PerkZilla’s referral engine and framework-agnostic frontend tooling for enterprise clients: premature horizontal slicing kills velocity before it saves consistency.

Why Micro Frontends? The Real Problem Statement

Monolithic frontends do not scale with teams. They scale with repositories.

Symptoms of a Monolith Bottleneck

One team’s PR blocks every other team’s release.
Shared component library becomes a political negotiation.
Bundle size grows 40% per quarter despite tree-shaking.
Onboarding a new team takes 3 sprints just to understand the codebase.

Micro frontends solve the team problem. Not the performance problem.

Core Decomposition Strategies

Vertical Micro Frontends (Domain-Owned Slices)

Definition: Each team owns a complete vertical slice. UI, business logic, and data pipeline for one domain. No shared runtime dependencies between slices.

// vertical-loader.js
// Each domain registers itself independently at runtime
const domainRegistry = {};

export function registerDomain(name, loadFn) {
  // Teams deploy their own chunk; loader fetches on demand
  domainRegistry[name] = loadFn;
}

export async function loadDomain(name, containerEl) {
  if (!domainRegistry[name]) {
    throw new Error(`Domain "${name}" is not registered.`);
  }
  // Clean mount — no shared state contamination
  const module = await domainRegistry[name]();
  module.mount(containerEl);
  return module;
}

// Team A registers their checkout domain
registerDomain('checkout', () => import('https://checkout.cdn.example.com/entry.js'));

// Team B registers their profile domain — fully independent
registerDomain('profile', () => import('https://profile.cdn.example.com/entry.js'));
// vertical-loader.js
// Each domain registers itself independently at runtime
const domainRegistry = {};

export function registerDomain(name, loadFn) {
  // Teams deploy their own chunk; loader fetches on demand
  domainRegistry[name] = loadFn;
}

export async function loadDomain(name, containerEl) {
  if (!domainRegistry[name]) {
    throw new Error(`Domain "${name}" is not registered.`);
  }
  // Clean mount — no shared state contamination
  const module = await domainRegistry[name]();
  module.mount(containerEl);
  return module;
}

// Team A registers their checkout domain
registerDomain('checkout', () => import('https://checkout.cdn.example.com/entry.js'));

// Team B registers their profile domain — fully independent
registerDomain('profile', () => import('https://profile.cdn.example.com/entry.js'));


Why this works:

Each domain deploys independently. Zero coordination overhead on releases.
Failure is isolated. Checkout crashing does not bring down Profile.
Follows the Single Responsibility Principle at the team level, not just the component level.

Q: Doesn’t vertical slicing duplicate shared UI components across domains?

A: Yes — and that is the correct trade-off at scale. Shared component libraries become coordination bottlenecks that violate team autonomy. The solution is a design token layer (CSS custom properties + a shared design system npm package with a strict semver contract), not runtime component sharing. Teams consume tokens, not components.

Horizontal Micro Frontends (Layer-Owned Slices)

Definition: Teams own specific horizontal layers across the entire application — one team for the shell/nav, one for shared UI, one for data access. All vertical features integrate through these layers.

// shell.js
// The shell team owns global layout and navigation
// Vertical teams inject their content into defined slots

export class AppShell {
  constructor(config) {
    this.slots = config.slots; // { header, main, footer, sidebar }
    this.activeRoutes = new Map();
  }

  async navigate(route) {
    const domainLoader = this.activeRoutes.get(route);
    if (!domainLoader) {
      console.warn(`No micro frontend registered for route: ${route}`);
      return;
    }

    // Shell controls the chrome; domain controls the content slot only
    const mainSlot = document.querySelector(this.slots.main);
    this.unmountCurrent(mainSlot);

    const { mount, unmount } = await domainLoader();
    mount(mainSlot);

    // Store unmount for cleanup on next navigation
    this.currentUnmount = unmount;
  }

  unmountCurrent(container) {
    if (this.currentUnmount) {
      this.currentUnmount(container);
      this.currentUnmount = null;
    }
  }
}
// shell.js
// The shell team owns global layout and navigation
// Vertical teams inject their content into defined slots

export class AppShell {
  constructor(config) {
    this.slots = config.slots; // { header, main, footer, sidebar }
    this.activeRoutes = new Map();
  }

  async navigate(route) {
    const domainLoader = this.activeRoutes.get(route);
    if (!domainLoader) {
      console.warn(`No micro frontend registered for route: ${route}`);
      return;
    }

    // Shell controls the chrome; domain controls the content slot only
    const mainSlot = document.querySelector(this.slots.main);
    this.unmountCurrent(mainSlot);

    const { mount, unmount } = await domainLoader();
    mount(mainSlot);

    // Store unmount for cleanup on next navigation
    this.currentUnmount = unmount;
  }

  unmountCurrent(container) {
    if (this.currentUnmount) {
      this.currentUnmount(container);
      this.currentUnmount = null;
    }
  }
}

Why this works:

The shell team enforces global navigation consistency without domain teams touching it.
Accessibility (ARIA roles, focus management) is centralized — one team owns it correctly.
Fits the Open/Closed Principle: shell is open for domain extension, closed for shell modification.

Q: How do you prevent the shell team from becoming a release bottleneck?

A: Contract-first development. The shell exposes a slot manifest (a JSON schema). Domain teams integrate against the schema, not the shell source. The shell ships on its own release cycle. Domain teams ship on theirs. Breaking changes in the schema trigger a versioned migration — not a coordinated freeze.

The Hybrid Architecture: The Production-Grade Pattern

Definition: Horizontal layers own shared chrome and infrastructure. Vertical slices own domain business logic and page-level content. Both layers communicate through an event bus, not direct imports.

// event-bus.js
// Decoupled communication between horizontal and vertical layers
// No direct imports between micro frontends

const subscribers = new Map();

export const EventBus = {
  emit(event, payload) {
    const handlers = subscribers.get(event) ?? [];
    // Defensive copy prevents handler mutation mid-emit
    [...handlers].forEach(fn => fn(payload));
  },

  on(event, handler) {
    if (!subscribers.has(event)) {
      subscribers.set(event, new Set());
    }
    subscribers.get(event).add(handler);
    // Return unsubscribe fn — critical for preventing memory leaks on unmount
    return () => subscribers.get(event).delete(handler);
  },
};

// ---- Checkout domain (vertical) ----
// checkout/entry.js
import { EventBus } from 'shared/event-bus';

export function mount(container) {
  // Notify the horizontal shell to update the cart badge
  EventBus.emit('cart:updated', { itemCount: 3 });
}

// ---- Shell (horizontal) ----
// shell/header.js
import { EventBus } from 'shared/event-bus';

const unsubscribe = EventBus.on('cart:updated', ({ itemCount }) => {
  document.querySelector('#cart-badge').textContent = itemCount;
});

// Clean up when shell unmounts (rare but necessary for SSR/testing)
window.addEventListener('unload', unsubscribe);
// event-bus.js
// Decoupled communication between horizontal and vertical layers
// No direct imports between micro frontends

const subscribers = new Map();

export const EventBus = {
  emit(event, payload) {
    const handlers = subscribers.get(event) ?? [];
    // Defensive copy prevents handler mutation mid-emit
    [...handlers].forEach(fn => fn(payload));
  },

  on(event, handler) {
    if (!subscribers.has(event)) {
      subscribers.set(event, new Set());
    }
    subscribers.get(event).add(handler);
    // Return unsubscribe fn — critical for preventing memory leaks on unmount
    return () => subscribers.get(event).delete(handler);
  },
};

// ---- Checkout domain (vertical) ----
// checkout/entry.js
import { EventBus } from 'shared/event-bus';

export function mount(container) {
  // Notify the horizontal shell to update the cart badge
  EventBus.emit('cart:updated', { itemCount: 3 });
}

// ---- Shell (horizontal) ----
// shell/header.js
import { EventBus } from 'shared/event-bus';

const unsubscribe = EventBus.on('cart:updated', ({ itemCount }) => {
  document.querySelector('#cart-badge').textContent = itemCount;
});

// Clean up when shell unmounts (rare but necessary for SSR/testing)
window.addEventListener('unload', unsubscribe);

Why this works:

Vertical and horizontal teams are fully decoupled at the import level.
The event bus is the only shared runtime contract.
Memory leak prevention via unsubscribe functions follows SOLID’s Dependency Inversion — teams depend on the abstraction (EventBus interface), not implementations.
Framework-agnostic. React, Vue, Svelte, or vanilla JS — all play nicely.

Q: Doesn’t a shared event bus create hidden coupling between domains?

A: Only if event names are undocumented. The solution is an event schema registry — a versioned JSON file listing all sanctioned events, their payload shapes, and owning teams. Undocumented events fail in CI. This is the exact pattern I implement for enterprise clients: coupling through documented contracts, not invisible side effects.

Module Federation: The Webpack/Vite Layer

Definition: Module Federation is a runtime dependency sharing mechanism. Micro frontends expose and consume JavaScript modules across deployment boundaries without bundling shared code redundantly.

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

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'checkout',
      filename: 'remoteEntry.js',
      exposes: {
        // Only expose the public contract — not internals
        './CheckoutPage': './src/pages/CheckoutPage',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
        // Design tokens shared — components are NOT shared
        '@company/design-tokens': { singleton: true },
      },
    }),
  ],
};

// webpack.config.js — Shell (host)
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        // Resolved at runtime — not compile time
        checkout: 'checkout@https://checkout.cdn.example.com/remoteEntry.js',
        profile: 'profile@https://profile.cdn.example.com/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};
// webpack.config.js — Checkout MFE (remote)
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'checkout',
      filename: 'remoteEntry.js',
      exposes: {
        // Only expose the public contract — not internals
        './CheckoutPage': './src/pages/CheckoutPage',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
        // Design tokens shared — components are NOT shared
        '@company/design-tokens': { singleton: true },
      },
    }),
  ],
};

// webpack.config.js — Shell (host)
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        // Resolved at runtime — not compile time
        checkout: 'checkout@https://checkout.cdn.example.com/remoteEntry.js',
        profile: 'profile@https://profile.cdn.example.com/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.0.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
      },
    }),
  ],
};

Why this works:

singleton: true prevents React version mismatch crashes — the most common Module Federation production bug.
Remotes resolve at runtime. Teams deploy independently without rebuilding the shell.
Shared design tokens (not components) enforce visual consistency without coupling component lifecycles.

Q: What happens if a remote MFE is unavailable at runtime?

A: Wrap every remote import in an Error Boundary with a fallback UI. Never let a missing remote take down the shell. Additionally, host a last-known-good version of each remoteEntry.js in a fallback CDN path. Circuit-breaker pattern at the loader level — not the component level.

Performance Architecture for Micro Frontends

Bundle Strategy

Each MFE has its own build pipeline. No shared build graphs.
Shared libraries (react, lodash) are federated — loaded once.
Route-based code splitting per MFE, not per component.

Critical Rendering Path

// Prioritized loading strategy — shell loads first, domains on demand
async function bootstrapApp() {
  // Step 1: Shell (critical path — blocking)
  await import('./shell/bootstrap');

  // Step 2: Above-the-fold domain (deferred but prioritized)
  const heroRoute = window.location.pathname.split('/')[1] || 'home';
  import(/* webpackPrefetch: true */ `./domains/${heroRoute}/entry`);

  // Step 3: Remaining domains (idle load)
  requestIdleCallback(() => {
    prefetchOtherDomains(heroRoute);
  });
}
// Prioritized loading strategy — shell loads first, domains on demand
async function bootstrapApp() {
  // Step 1: Shell (critical path — blocking)
  await import('./shell/bootstrap');

  // Step 2: Above-the-fold domain (deferred but prioritized)
  const heroRoute = window.location.pathname.split('/')[1] || 'home';
  import(/* webpackPrefetch: true */ `./domains/${heroRoute}/entry`);

  // Step 3: Remaining domains (idle load)
  requestIdleCallback(() => {
    prefetchOtherDomains(heroRoute);
  });
}

Performance Rule: The shell’s Time to Interactive must be under 1.5s on a 4G connection. Domain MFEs contribute to LCP, not TTI.

Testing Strategy for Micro Frontends

Layer	Test Type	Owned By
Individual MFE	Unit + Component	Domain Team
MFE Contract (event bus, slot schema)	Contract Tests (Pact)	Platform Team
Full Integration (shell + domains)	E2E (Playwright)	QA/Platform Team
Visual Consistency	Visual Regression (Chromatic)	Design System Team

The Architect Rule: Contract tests replace integration tests between MFEs. Integration tests are for user journeys, not for proving two MFEs can talk.

Frequently Asked Questions

What is the difference between vertical and horizontal micro frontends?

Vertical micro frontends assign full domain ownership (UI + logic + data) to one team. Horizontal micro frontends assign layer ownership (shell, data, UI components) across teams. Vertical optimizes for delivery speed. Horizontal optimizes for UI consistency.

How do micro frontends communicate without tight coupling?

Through a shared, documented event bus or custom events on the browser’s window object. Direct imports between micro frontends are an anti-pattern. All contracts must be versioned and schema-validated to prevent hidden coupling.

When should you NOT use micro frontends?

When your team has fewer than 5 frontend engineers. Micro frontends introduce operational overhead (CI pipelines, CDN routing, version management). The break-even point for most teams is 3+ independent frontend squads shipping weekly.

How does Module Federation differ from iFrame-based micro frontends?

Module Federation shares JavaScript modules at runtime — same DOM, shared memory, native browser APIs. iFrames are fully isolated sandboxes — separate DOM, separate memory, constrained communication. Module Federation is faster and more integrated but requires strict versioning discipline. iFrames are safer for third-party or untrusted code.

About the Architect

This architecture pattern was applied during the rebuild of PerkZilla, a referral and viral-loop platform serving concurrent campaigns across multiple brand domains.

I work on framework-agnostic frontend infrastructure for product teams operating at scale.

The event bus and contract-testing patterns described here are drawn from live production audits — not theoretical exercises.

Related: At that scale, caching strategy is one of the levers that keeps latency flat. See Types of caching for developers.

Scaling Micro Frontend Architecture for 10M+ User Platforms Without Losing Team Velocity

The Insight AI Won’t Give You

Why Micro Frontends? The Real Problem Statement

Symptoms of a Monolith Bottleneck

Core Decomposition Strategies

Vertical Micro Frontends (Domain-Owned Slices)

Horizontal Micro Frontends (Layer-Owned Slices)

The Hybrid Architecture: The Production-Grade Pattern

Module Federation: The Webpack/Vite Layer

Performance Architecture for Micro Frontends

Bundle Strategy

Critical Rendering Path

Testing Strategy for Micro Frontends

Frequently Asked Questions

About the Architect

Want to talk about this kind of work?