Micro Frontends in React

Micro frontend architecture applies independent ownership to the browser. A shell supplies the page frame and cross-cutting services; domain applications own vertical slices such as search, checkout, billing, or analytics. Each slice should have its own release decision and failure boundary. If every release still needs a shared integration meeting, the organization has distributed the code without distributing authority.

The biggest mistake is sharing too much. Webpack Module Federation can share React, design-system packages, state libraries, utilities, and feature components at runtime. Every shared item is also a version contract and a possible coordination point. Share the smallest stable foundation. Domain behavior belongs with the team accountable for that domain.

Microfrontends are independently developed and deployed frontend applications composed into one product experience. The boundary is normally a business domain or route, not a visual atom. Search, account, checkout, and analytics can be sensible domains. Header, button, form field, and modal are usually design-system components, not independent applications. Splitting by UI layer leaves several teams changing one feature and defeats the ownership goal. React does not supply micro frontend architecture by itself; it renders each application. Composition can happen at build time, on the server, through browser routing, through Web Components, or at runtime with Module Federation. AWS describes a parent application that integrates independently delivered child applications; the important word is independently. Separate repositories without separate deployment authority are still a coordinated system. A micro frontend should remain useful, testable, and releasable when neighboring applications change on a different schedule.

The boundary is organizational before it is technical.

Do not adopt this pattern to fix slow builds, untidy folders, or weak module boundaries. A monorepo, route-level code splitting, dependency rules, and clear ownership can solve those problems with less runtime machinery. A team of six engineers rarely needs six deployable frontends. It needs a codebase people can understand.

The pattern becomes defensible when several durable teams own distinct product domains, deployment coordination delays customer value, different areas need different release cadences, and the organization is prepared to operate multiple artifacts. Measure the present constraint first: time waiting for another team, release frequency, rollback blast radius, and the percentage of changes crossing domain boundaries.

Webpack Module Federation lets one build expose modules and another load them at runtime. In React systems, React and React DOM are commonly configured as singleton shared dependencies because two incompatible runtimes can break hooks and context identity. The host and remote still need an explicit compatibility policy. Automatic version negotiation is not a substitute for contract tests.

Keep the shared surface boring: design tokens, a small component foundation, identity capabilities, navigation, and telemetry adapters. Do not create a giant shared package for domain models, API clients, feature flags, and every utility function. Shared code changes at the speed of its slowest consumer. Duplication is sometimes cheaper than permanent coordination.

The shell should own top-level URLs; a remote can own routing beneath its mounted prefix. Define who handles redirects, unknown routes, browser history, and deep links before teams ship independently. URL state is often the cleanest cross-application contract because it survives refresh, supports links, and does not couple React component trees.

For communication, prefer browser events or small typed capability interfaces for facts such as CartUpdated or PaymentCompleted. Use APIs as the source of durable domain state. A shared Redux store looks convenient, but it lets any remote read or mutate another team's internals and ties deployments to one state shape. Global state should be limited to concerns that are truly global: authenticated identity, locale, consent, and perhaps a small navigation contract.

Independent deployment needs more than separate pipelines. Every remote should publish a versioned artifact, compatibility metadata, source maps, release markers, and a rollback target. Test contracts between shell capabilities and remote expectations. Run a small integration suite against the deployed composition, then let each domain team own deeper tests inside its boundary.

Monitor real-user performance and errors by remote version. Track load failures, remote-entry latency, JavaScript bytes, duplicate dependencies, React render errors, Core Web Vitals, and failed API calls. A shell-level dashboard without remote tags tells operators that the site is broken but not who can fix it. Add kill switches for optional remotes and a stable fallback for critical routes.

At PropertyGuru, I led a monolith-to-micro-frontend migration for four product teams. We divided ownership by business domain—listings, payments, analytics, and agent tools—rather than by UI layer. The result was not four arbitrary React bundles. Each team received a vertical slice it could change and deploy with fewer cross-team release dependencies.

Webpack Module Federation provided runtime composition, but restraint mattered more than the tool. We kept shared code to design tokens, authentication, navigation, and strict service contracts. A unified payment capability was exposed behind a stable interface so consumer teams did not need its internal implementation. That is the test I now use: if a boundary does not reduce the number of people required to release a change, it is in the wrong place.