Core Micro-Frontend Architecture Tradeoffs #

Micro-frontend architecture splits a single web application into independently built, deployed, and owned slices that compose into one experience at runtime. This guide is written for frontend architects, tech leads, and engineering managers who are deciding whether to adopt the pattern — and, if they do, how to keep it from becoming more expensive than the monolith it replaced.

The central promise is organizational, not technical: teams ship on their own cadence without queuing behind a shared release train. The central cost is also organizational: you trade one build, one deploy, and one dependency graph for many of each, plus the runtime machinery and observability needed to make independent parts behave as a coherent whole.

That tradeoff is worth making for some teams and actively harmful for others. The sections below give you the thresholds for deciding, the concepts you need to reason about composition, an annotated reference configuration, a team topology that survives contact with reality, and a phased roadmap with explicit go/no-go gates. By the end you should be able to say not just “should we do this” but “what specifically would we build, who would own it, and how would we know it was working.”

Who this is for — and when it is warranted #

Micro-frontends are warranted when multiple teams need to deploy independently to distinct parts of the same product. Remove any one of those three conditions and the case weakens fast. A single team gains nothing from runtime composition except latency and tooling. Two teams that always release together gain nothing from independent pipelines. Two teams working on the same tightly-coupled checkout flow gain nothing from a boundary that cuts straight through their shared domain.

The pattern is not a performance optimization, a code-quality strategy, or a way to use multiple frameworks for its own sake. It is a way to scale the number of teams that can work on one frontend without their changes colliding. If your bottleneck is something else — slow builds, flaky tests, unclear code ownership inside a single team — fix that first; micro-frontends will not.

It also helps to be honest about what “warranted” feels like in practice. The clearest signal is recurring, visible frustration with the shared release process: a team holds a finished feature for days because someone else’s change broke the trunk, or a deploy is reverted and everyone’s work rolls back with it. When that friction is chronic rather than occasional, the organizational pressure is real and the pattern has something concrete to relieve. When it is hypothetical — “we might want to deploy independently someday” — you are buying insurance against a cost you have not yet incurred, and the premium is high.

Decision criteria: the thresholds that matter #

Three measurable signals tell you whether you have crossed into the territory where micro-frontends pay off. Treat them as a checklist, not a gradient — you want clear “yes” answers on at least two before committing.

Team size and count #

The unit of analysis is independent teams, not headcount. One team of twenty engineers should not split its own frontend into remotes; coordination inside a team is cheap, and runtime composition just adds latency. The pattern starts earning its keep at roughly three or more teams that each own a coherent slice of the product and would otherwise contend for the same repository and release pipeline.

Below that, a well-modularized monolith with clear code ownership (CODEOWNERS, package boundaries, trunk-based development) gets you most of the autonomy with none of the runtime tax. The guide on when to avoid micro-frontends for small teams walks through the specific signals that mean you are too early.

Release cadence #

Micro-frontends solve a deployment-coupling problem. If your teams genuinely need to release multiple times per week, on schedules they control, and the shared release train is forcing them to batch and wait, independent deploys are the direct fix. If everyone is comfortable shipping together every sprint, the coupling is not hurting you, and you would be paying for a freedom nobody is using.

Measure the actual pain: how often does a team have a change ready that it cannot ship because of someone else’s broken build or unfinished feature? If the answer is “rarely,” the cadence threshold is not met.

Domain complexity #

The frontend has to decompose along bounded contexts — durable business capabilities like catalog, checkout, and account, each with its own data, language, and rules. When those contexts are genuinely distinct, a boundary between them is natural and stable. When they are entangled (every screen touches every domain), any boundary you draw will be crossed constantly, generating exactly the cross-team coupling the pattern is supposed to eliminate.

Getting these lines right is the highest-leverage decision in the whole effort. The dedicated guide on defining application boundaries covers how to map domains to ownership without splitting a single user flow across three teams.

Core concept map #

A handful of concepts do most of the load-bearing work. Get fluent in these and the rest of the architecture follows.

Bounded contexts #

A bounded context is a slice of the business with its own model and vocabulary. In a frontend, it becomes one remote owned by one team. The boundary should match a seam in the product where the user mentally switches tasks — browsing versus paying versus managing their account — because those seams change for different reasons and at different rates.

Host and remote roles #

The host (or shell) is the application the browser loads first. It owns the global layout, top-level routing, authentication shell, and the shared-dependency contract. It deliberately owns as little business logic as possible.

A remote is an independently built bundle that the host loads at runtime and mounts into a region of the page. Each remote exposes a small public surface — usually a mount function or a component — and keeps everything else private. The host knows the remote’s URL and its exposed module names; it knows nothing about its internals.

Build-time vs runtime vs iframe composition #

Composition is where the integration actually happens, and you have three broad strategies with very different properties.

• Build-time composition publishes each slice as an npm package that the host installs and bundles. It is simple and fast at runtime but reintroduces the coupling you were trying to escape: every slice change forces a host rebuild and redeploy. It is rarely true micro-frontends.
• Runtime composition loads remotes over the network when the page runs, typically via Module Federation or import maps. The host and remotes deploy independently. This is the default for serious micro-frontend systems and what most of this guide assumes. The Module Federation implementation guide covers the Webpack and Vite mechanics in depth.
• iframe composition gives the hardest isolation — separate DOM, separate JS context, separate CSS — at the cost of clumsy cross-frame communication, duplicated dependencies, and accessibility and routing friction. Reserve it for third-party or legacy slices you cannot trust to share a runtime.

Most teams land on runtime composition with Module Federation, falling back to iframes only for untrusted content. The rest of this guide follows that mainstream path.

The 2026 runtime-composition landscape #

“Runtime composition via Module Federation” no longer means one thing. By 2026 the choice has fractured into three mature options with different bundler coupling and different operational shapes, and picking the wrong one locks you into migration debt.

• Module Federation 2.0 (@module-federation/enhanced) is the bundler-agnostic successor to Webpack 5’s bundled plugin. It runs on Webpack and Rspack, ships a typed runtime with a real plugin API, a runtime manifest (mf-manifest.json) that decouples the host from each remote’s chunk layout, automatic type sharing, and a dev-time chrome extension for inspecting the shared scope. New systems should standardize on @module-federation/enhanced rather than the legacy webpack.container import; the older API still works but receives no new capabilities.
• Vite federation via @module-federation/vite brings genuine parity with the Webpack runtime — the same manifest format and shared-scope negotiation — so a Vite remote and a Webpack/Rspack host can interoperate. The earlier @originjs/vite-plugin-federation predates that convergence and should be treated as legacy. Mixing bundlers across teams is now realistic, but only when every party speaks the MF 2.0 manifest.
• Native Federation / import maps lean on the browser’s own ES module loader and a standard <script type="importmap"> instead of a bundler runtime. There is no per-bundler plugin lock-in and the entry cost is near zero, but you give up automatic shared-scope negotiation and type sharing — you manage versions and singletons yourself. This path suits teams that want minimal tooling or framework neutrality; the import maps guide compares it head to head with Module Federation.

A practical default for a greenfield system in 2026: Rspack or Vite with @module-federation/enhanced for the manifest, type sharing, and runtime plugins, reserving import maps for the simplest two-team setups and iframes for untrusted content.

Server-side rendering and React Server Components #

Composition gets materially harder the moment you need SSR or streaming, and this is where many 2026 adoptions stall. Federating client bundles is solved; federating a rendered HTML stream across independently deployed remotes is not, by itself. Each remote must render on the server, the host must stitch those fragments into one document and one hydration pass, and the shared scope has to resolve identically on the server and the client or hydration mismatches appear.

React Server Components add a sharper constraint: an RSC payload is tied to the exact module graph and React version that produced it, so a remote that ships Server Components effectively couples its React build to the host’s far more tightly than a client-only remote does. Treat cross-remote RSC and streaming SSR as an advanced capability that needs first-class platform investment — not something a feature team bolts on. If SSR is a hard requirement from day one, prototype the streaming-and-hydration path during the pilot rather than discovering its cost at scale.

The shared scope #

One more concept underpins runtime composition: the shared scope. When the host boots, it publishes a registry of the dependencies it is willing to share and at which versions. As each remote initializes, it negotiates against that registry — borrowing the host’s React if the versions are compatible, or loading its own if not. This negotiation is what lets independently built bundles cooperate on a single React instance without anyone hard-coding the other’s build output. Understanding the shared scope is the key to reasoning about both bundle size and the version-skew failures covered later; almost every subtle micro-frontend bug traces back to a misunderstanding of how this negotiation resolves.

Annotated canonical Module Federation config #

Here is a reference host configuration using the 2026-standard @module-federation/enhanced plugin, with every meaningful field explained. This is the contract that makes runtime composition work, so it rewards careful reading. It is written for Rspack/Webpack; the Vite equivalent (@module-federation/vite) takes the same option shape.

// rspack.config.js / webpack.config.js — host (shell) application
const { ModuleFederationPlugin } = require('@module-federation/enhanced/rspack');
const deps = require('./package.json').dependencies;

module.exports = {
  output: {
    // Must be a stable, absolute URL so remotes resolve their chunks
    // correctly no matter which route loaded them. In MF 2.0 you can
    // also set output.publicPath to 'auto' and let the runtime infer it.
    publicPath: 'https://cdn.example.com/host/',
  },
  plugins: [
    new ModuleFederationPlugin({
      // Unique global name for this container. Remotes reference the host
      // and the host references remotes by these names.
      name: 'host',

      // Point at each remote's mf-manifest.json (MF 2.0) rather than the
      // raw remoteEntry.js. The manifest decouples the host from the
      // remote's chunk layout and carries metadata + exposed types.
      remotes: {
        catalog: 'catalog@https://cdn.example.com/catalog/mf-manifest.json',
        checkout: 'checkout@https://cdn.example.com/checkout/mf-manifest.json',
      },

      // MF 2.0 runtime plugins: retry on a failed remote fetch, report
      // load timings to telemetry, or pin a remote to a specific version
      // from a registry. This is the seam for operational guardrails.
      runtimePlugins: ['./mf-runtime/retry-and-telemetry.js'],

      // The shared scope is the single most important governance lever.
      // singleton:true forces ONE instance across host + all remotes —
      // mandatory for React, react-dom, and any stateful runtime where
      // two copies would break hooks, context, or a global store.
      shared: {
        react: {
          singleton: true,
          requiredVersion: deps.react,
          // Hard-fail on an incompatible major rather than silently
          // running two Reacts (which corrupts hooks at runtime).
          strictVersion: true,
        },
        'react-dom': {
          singleton: true,
          requiredVersion: deps['react-dom'],
          strictVersion: true,
        },
      },
    }),
  ],
};

Three fields deserve emphasis. singleton: true is non-negotiable for React and any library that holds module-level state — two React instances produce the infamous “invalid hook call” and silently broken context. strictVersion: true turns a version mismatch into a loud build/runtime error instead of a subtle production bug. runtimePlugins is the MF 2.0 addition that matters most operationally: it is where retry, fallback, version pinning, and load telemetry hook into the runtime instead of being scattered across feature code. Deciding exactly which packages belong in shared, and at what versions, is its own discipline; the guide on avoiding bundle duplication shows how to measure the payload impact before you over-share.

The remote side mirrors this, exposing modules instead of consuming them:

// rspack.config.js — a remote application (catalog)
const { ModuleFederationPlugin } = require('@module-federation/enhanced/rspack');
const deps = require('./package.json').dependencies;

module.exports = {
  output: { publicPath: 'https://cdn.example.com/catalog/' },
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalog',
      // The runtime entry the host loads; MF 2.0 also emits the
      // mf-manifest.json the host points at above.
      filename: 'remoteEntry.js',
      // The remote's public API — keep this surface tiny and stable.
      // Everything not listed here stays private to the team.
      exposes: {
        './ProductList': './src/ProductList',
      },
      // Emit a typed contract for consumers — MF 2.0 generates and
      // serves @mf-types so the host gets type-checked remote imports
      // without a separate publish step.
      dts: { generateTypes: true, consumeTypes: true },
      // Remotes declare the SAME shared contract so the host can
      // negotiate a single instance at load time.
      shared: {
        react: { singleton: true, requiredVersion: deps.react },
        'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },
      },
    }),
  ],
};

Because remotes are fetched over the network, you must plan for one being unavailable. With MF 2.0 the cleanest place to do this is the typed runtime API, which negotiates the shared scope for you — no more reaching for __webpack_init_sharing__:

// mf-runtime/load.js — load a remote module with a bundled fallback.
import { loadRemote } from '@module-federation/enhanced/runtime';

export async function loadProductList() {
  try {
    // The runtime handles shared-scope init and manifest resolution.
    const mod = await loadRemote('catalog/ProductList');
    return mod.default;
  } catch (error) {
    console.error('Failed to load catalog/ProductList:', error);
    // Host keeps running; the region shows a safe fallback.
    return (await import('./fallbacks/RemoteUnavailable')).default;
  }
}

That catch block is the difference between “the catalog is slow today” and “the whole store is down.” Better still, push the retry-then-fallback policy into a runtimePlugin so every remote inherits it uniformly rather than each call site reimplementing it. Treat every remote boundary as a place a network call can fail.

Team topology and ownership #

The architecture only works if it mirrors how the organization is actually structured. Conway’s Law is not a warning here; it is the operating principle.

Platform team owns the contract, not the features #

A small platform team owns the host shell, the shared-dependency policy, the CI/CD templates, contract-testing infrastructure, the design-system package, and the observability backbone. They are a force multiplier: they build the paved road so feature teams do not each reinvent it. Critically, they own no business domain — the moment the platform team becomes a bottleneck for feature work, the autonomy benefit evaporates.

Stream-aligned teams own a remote end to end #

Each feature team owns one remote (or a small set) from code to production: build, test, deploy, monitor, and on-call. They control their cadence and their internal choices. Their only obligations to the outside world are the shared-dependency contract and the small public surface they expose. Within that boundary they are sovereign.

The contract between them #

Communication across remotes flows through documented, typed interfaces — never through reaching into another team’s DOM or a hidden global. Shared concerns (auth tokens, design tokens, telemetry) are provided by the host or a versioned package, not improvised per team. Keeping these contracts honest as teams evolve is the subject of the guide on managing cross-team coupling, and the cross-app state and context sharing guide covers the patterns for passing data across that boundary without recreating a distributed monolith.

Strategic tradeoffs #

Every benefit of micro-frontends has a paired cost. Naming both honestly is the only way to make a defensible decision.

The pattern that should jump out: the costs are real, recurring, and land disproportionately on the platform team and end users, while the benefits accrue to feature teams. That asymmetry is exactly why micro-frontends fail in organizations without a funded platform function — nobody is positioned to absorb the operational tax. The guide on versioning strategies for remote apps and the one on deployment and observability cover the two cost centers — dependency skew and operational visibility — that most often blow up in production.

There is also a tradeoff that resists tabulation because it shows up only over months: architectural drift. In a monolith, a single review can catch a pattern violation anywhere in the codebase. Across independently owned remotes, each team evolves its own conventions, and divergence accumulates silently until a shared change — a design-system upgrade, a new auth flow — has to be applied N different ways. The countermeasure is the same paved road that controls the other costs: shared templates, enforced contracts, and a design system that is consumed rather than copied. The decision is not whether to pay the governance cost but whether you are willing to fund the function that pays it continuously. A team that adopts the runtime mechanics without the governance discipline ends up with the distributed-systems failure modes and none of the distributed-systems benefits.

Adoption roadmap #

Do not decompose the whole frontend at once. Earn each phase with evidence, and define the go/no-go gate before you start so the decision is not made under sunk-cost pressure.

Phase 1 — Pilot #

Pick one non-critical domain with a clean boundary and a motivated team. Stand up the host shell, one remote, the shared-dependency contract, and a real deployment to the CDN. The goal is to validate mechanics and measure honest performance impact, not to ship something important.

Go/no-go to Phase 2: the remote deploys independently without rebuilding the host; first paint and Core Web Vitals stay within budget; the pilot team reports the workflow is better, not just different. If any of those fail, stop and fix the foundation — or conclude the pattern is not for you yet.

Phase 2 — Guardrails #

With one slice proven, build the paved road so the second and third teams do not start from scratch. That means CI/CD templates, the shared-dependency policy enforced in config, contract testing in the pipeline, distributed tracing and error-boundary telemetry, and a documented onboarding path. Add a second remote on top of these guardrails to prove they generalize.

Go/no-go to Phase 3: a new team can onboard a remote using the templates without platform-team hand-holding; a breaking change in one remote is caught by contract tests before production; you can trace a single user journey across remotes in your observability tooling.

The most common failure at this gate is declaring victory too early. If onboarding still requires a platform engineer to sit with the team for a day, the road is not yet paved — it is a footpath, and it will not survive five teams. Hold the gate until self-service is genuinely real, because Phase 3 multiplies whatever friction remains.

Phase 3 — Scale #

Now decompose the remaining domains, with governance automated rather than manual. Self-service onboarding, automated dependency-policy checks, progressive rollout, and rollback become routine. Commit here only if Phases 1 and 2 produced measurable velocity gains that exceed the ongoing infrastructure overhead. If the gains are ambiguous, the honest move is to stop at two or three remotes — a partial migration is a legitimate and often optimal end state.

Common pitfalls #

Each of these has bitten real teams. The pattern is the same: a shortcut that works for one slice quietly violates an assumption that only matters at scale.

Over-sharing dependencies #

Root cause: every utility library gets dumped into shared “to be safe,” inflating the initial payload and tangling version negotiation. Resolution: reserve singleton: true for libraries that genuinely cannot tolerate two instances (React, the store). Let stateless utilities load per remote, and measure before adding anything to the shared scope.

Two React instances #

Root cause: a remote omits the shared contract or pins an incompatible version, so the browser loads a second React; hooks throw “invalid hook call” intermittently. Resolution: declare React singleton: true with strictVersion: true everywhere, so a mismatch fails loudly at load instead of corrupting state silently.

CSS leaking across remotes #

Root cause: a remote ships global selectors that override the host or a sibling, because nothing isolates styles. Resolution: enforce scoped CSS (CSS Modules, a build-time prefix, or Shadow DOM) as a platform policy, not a per-team choice. Verify with visual regression tests in the pipeline.

Hidden coupling through globals #

Root cause: teams pass data by stashing it on window or reaching into another remote’s DOM, recreating a distributed monolith with none of the monolith’s compile-time safety. Resolution: require communication through typed, documented interfaces and shared providers; treat any direct cross-remote DOM or global access as a build-time failure.

Treating the pipeline like a monolith’s #

Root cause: independent deploys without distributed tracing, contract validation, or automated rollback, so a single remote can break a user journey nobody can debug. Resolution: make per-remote telemetry, contract tests, and manifest-pointer rollback table stakes before the third remote ships — exactly the Phase 2 guardrails.

FAQ #

When should a team avoid micro-frontends entirely?

When you have a single team, when teams already release comfortably on a shared cadence, or when the domains are too entangled to draw a stable boundary. Below roughly three independent teams owning distinct contexts, a modular monolith delivers most of the autonomy with none of the runtime and operational tax.

Do all remotes have to use the same framework?

Technically no — runtime composition can mount a React remote next to a Vue one. In practice, mixing frameworks multiplies bundle size, duplicates runtime, and complicates shared state, so the cost almost always outweighs the benefit. Standardize on one framework and treat exceptions (a legacy or third-party slice) as iframe-isolated.

How do micro-frontends affect Core Web Vitals?

Each remote adds at least one network request for its entry (or its mf-manifest.json), which can hurt LCP and FCP if loaded eagerly. Mitigate with HTTP/2 or HTTP/3 multiplexing, CDN edge caching, prefetching the next likely remote during idle time, and lazy-loading remotes below the fold. Measured well, lazy slices can improve first paint over a monolithic bundle. INP is the dimension to watch under hydration: many independently hydrating remotes can starve the main thread, so stagger or defer hydration of below-the-fold slices.

Which Module Federation tooling should we choose in 2026?

For a new system, standardize on @module-federation/enhanced (Module Federation 2.0) on Rspack or Webpack, and use @module-federation/vite for any Vite remotes — they share the same manifest format and shared-scope negotiation, so cross-bundler interop actually works. Reach for Native Federation / import maps only when you want minimal tooling or framework neutrality and are willing to manage singletons and versions by hand. The legacy webpack.container plugin and @originjs/vite-plugin-federation still function but predate the runtime, typed-contract, and manifest features you will want.

What state should be shared across remotes, and how?

Keep state local to each remote by default. Share only genuinely cross-cutting concerns — auth, the current user, theme — through the host or a versioned provider, never a sprawling global store. For the specific patterns, see the cross-app state and context sharing guide linked below.

Can we adopt micro-frontends incrementally?

Yes, and you should. Start with one non-critical remote behind the host shell while the rest stays monolithic, then peel off domains as the guardrails prove out. A partial migration that stops at two or three remotes is a perfectly good outcome if the velocity math says so.

Related #

• Defining Application Boundaries
• Avoiding Bundle Duplication
• Managing Cross-Team Coupling
• Versioning Strategies for Remote Apps
• Deployment & Observability

← Back to all guides