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'));
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.
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;
}
}
}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.
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);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.
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' },
},
}),
],
};Why this works:
singleton: trueprevents 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.
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);
});
}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
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.
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 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.
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‘s referral platform — a high-traffic viral loop engine serving concurrent campaigns across multiple brand domains.
As Founder @ Behind Methods Co and a Top 3.5% Vetted Senior Architect, I specialize in framework-agnostic frontend infrastructure for US and EU product teams scaling past Series B.
The event bus and contract-testing patterns described here are drawn from live production audits — not theoretical exercises.