Micro-frontends & Monorepo

1The reframe — MFEs solve an org problem, not a code problem

Micro-frontends are “an architectural style where independently deliverable frontend applications are composed into a greater whole.” [Fowler] But the reason to adopt them is almost never technical. The honest framing: you split the frontend so you can split the teams — independent deploys, independent stacks, end-to-end ownership. If you don't have a team-scaling problem, you don't have a micro-frontend problem.

The three benefits Fowler names — and they're all about people, not performance: [Fowler]

• Independent deployment — each MFE has its own CD pipeline, ships without cross-team coordination.
• Autonomous teams — vertical slices of a product, owned end-to-end, no handoffs.
• Incremental upgrades — migrate React 17→19, or escape a legacy framework, one slice at a time instead of a big-bang rewrite.

2How they're stitched together — the integration spectrum

“Micro-frontend” is a goal; the interesting question is where the composition happens. The core picture: three independently-built, independently-deployed apps (each its own team, repo, pipeline) are stitched into one page the user sees as a single product. Watch the shell load each slice on its own:

Fowler lists five approaches; know them as a spectrum from build-time (coupled) to runtime (decoupled): [Fowler]

Module Federation (Webpack 5 / now Rspack & the standalone @module-federation/* runtime) is the de-facto runtime tool: a host loads code from a remote at runtime and they can share dependencies (one React instance instead of three). single-spa is the orchestrator/router; import maps are the native-browser primitive. Know all three names. [module-federation.io]

// host webpack.config — load "cart" remote at runtime, share ONE React
new ModuleFederationPlugin({
  name: 'shell',
  remotes: { cart: 'cart@https://cart.example.com/remoteEntry.js' },
  shared: {
    react:      { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
  },
});
// singleton:true ⇒ load ONE shared copy. The version negotiation here
// is exactly where "version skew" lives (see §3).

3The costs — what you actually pay (this is the graded part)

Anyone can recite the benefits. A Lead names the bill. Five real costs, each with the one-liner you'd say in the room:

4Deep dive — two versions of the same library, resolved

This is the favourite follow-up: “Shell needs React 18.2, a remote was built against 18.3 — what actually happens?” Module Federation maintains a shared scope: a runtime registry where every container publishes the versions it brought and consumers resolve the best match. The outcome depends entirely on how you flagged that dependency in shared. [MF docs]

// The mental model: singleton = "one copy, highest wins, warn on mismatch".
shared: {
  react: { singleton: true, strictVersion: true, requiredVersion: '^18.2.0' },
}
// → exactly one React. If a remote shows up with an incompatible 17.x,
//   strictVersion makes it CRASH LOUDLY at load, not corrupt hooks silently.

Worked examples — predict the resolution, then reveal

The drill: read the config line, say the outcome out loud (how many copies? whose version wins? any warning/crash?), then click to check. Assume each party's requiredVersion is the default caret ^ of the version it declares (so same major = compatible) unless noted. Left border: clean · duplication / warning · crash.

5How micro-frontends talk to each other

The golden rule mirrors microservices: prefer the loosest coupling that does the job. The more two MFEs know about each other, the less independent they actually are. The hierarchy, loosest-to-tightest: [Thoughtworks]

// Decoupled sibling→sibling: search MFE fires, cart MFE listens. No import.
window.dispatchEvent(new CustomEvent('app:add-to-trip', { detail: { hotelId } }));
// cart MFE, mounted independently:
window.addEventListener('app:add-to-trip', e => addHotel(e.detail.hotelId));

6Wiring, deploying & caching remotes — the operational reality

First, two words people (and I, earlier) mix up

Get these straight and the rest is obvious:

• remoteEntry.js — the entry file (a "pointer"). A tiny JS file the remote publishes at a fixed, un-hashed URL (e.g. cart.example.com/remoteEntry.js). The host runs it to discover the remote's exposed modules and, crucially, which content-hashed chunk files hold the real code (e.g. cart.8f3a9c.js). It does not contain your components — it points at the chunks that do.
• mf-manifest.json — the manifest. A separate JSON file that Module Federation 2.0 also emits, describing the remote (its exposes, shared, remoteEntry, chunks). It's metadata the runtime/tooling reads. [MF runtime]

They're not the same thing — so I'll stop saying "manifest" loosely and just say entry file. The mental model that makes everything click: one small mutable pointer at a stable URL, pointing at many large immutable chunks whose names change every build.

Static vs dynamic remotes (with the runtime API)

// STATIC — URL is a compile-time constant in the host's build config:
remotes: { cart: 'cart@https://cart.example.com/remoteEntry.js' }

// DYNAMIC — URL comes from runtime config, loaded on demand:
import { init, loadRemote } from '@module-federation/enhanced/runtime';

const cfg = await fetch('/config.json').then(r => r.json()); // {cartUrl: '…/v1.2.3/remoteEntry.js'}
init({
  name: 'shell',
  remotes: [{ name: 'cart', entry: cfg.cartUrl }],   // ← decided at RUNTIME, not build
});
const { addToCart } = await loadRemote('cart/api');  // lazy-load an exposed module

The paradox you spotted — “if it's a fixed URL and it's cached, how does it ever update?”

Exactly the right question. With a static remote the host always fetches the same URL: …/remoteEntry.js. When the remote team redeploys, they overwrite that file in place — same URL, new contents that now point at the new hashed chunks. So:

• If the browser fetches that file fresh → it sees the new pointer → loads the new chunks → auto-updates, no host redeploy. ✅ (the whole payoff.)
• If that file is cached → the host keeps reading the old pointer → it never sees the update. ❌ That's the contradiction — and it's real.

So the resolution is a deliberate split: the entry file is the one thing you must serve un-cached (it's tiny — revalidating it on every load is cheap), while the heavy chunks it points to are cached forever, safely, because their filenames change when their content changes. Play it through both ways:

Solutions — defense in depth

• Never long-cache the entry file. Serve remoteEntry.js with Cache-Control: no-cache / short TTL / must-revalidate (or cache-bust with ?t=<timestamp>) so the host always revalidates and gets the fresh pointer.
• Long-cache the chunks. They're content-hashed, so Cache-Control: immutable, max-age=31536000 — cache forever, safely. (Entry fresh, chunks immutable = the whole trick.)
• Retain old chunks for a window after deploy (don't hard-purge). In-flight sessions and any briefly-stale entry still resolve → no ChunkLoadError mid-rollout.
• Drive versions from a runtime config/registry. Map logical name → current version URL; deploy = update the registry, rollback = repoint it (config flip, no host rebuild). Serve versioned immutable entry paths (/v1.2.3/remoteEntry.js) + an atomic swap to kill the overwrite-mid-deploy race.
• Error boundary + retry/fallback per remote so a 404'd/unreachable entry degrades gracefully instead of white-screening (ties §11 fate-sharing).

# The one cache rule that prevents the outage:
remoteEntry.js   →  Cache-Control: no-cache                  # tiny pointer — always revalidate
cart.8f3a9c.js   →  Cache-Control: immutable, max-age=31536000  # hashed → cache forever

“If static + no-cache already updates correctly, why do we need dynamic?”

Because they fix different axes. no-cache answers “give me the freshest contents of a URL I already know.” Dynamic answers “which URL, which version, and whether to load at all — decided at runtime.” Static + no-cache can't touch that second axis: it only ever gives you always-latest, and “always-latest with no way to pin or roll back” is a liability on a revenue funnel.

So static + no-cache is perfectly fine for a small, fixed set of always-latest remotes. The moment you need version control, rollback, per-env URLs, or conditional loading, that's the job dynamic does — and no-cache was never the tool for any of it.

Where the version lives — the config.json registry

In the dynamic snippet the host fetched /config.json. That's the host-level registry: a tiny JSON mapping each logical remote → the exact versioned entry URL to load right now. Editing it is how you release or roll back.

// config.json — the host's version registry (a "pointer to pointers")
{
  "cart":    "https://cart.example.com/v1.2.3/remoteEntry.js",
  "search":  "https://search.example.com/v4.0.1/remoteEntry.js",
  "account": "https://account.example.com/v2.7.0/remoteEntry.js"
}
// release  = bump "v1.2.3" → "v1.2.4";  rollback = set it back to "v1.2.2"

Don't mix the three “pointer-ish” files — they sit at two levels:

• config.json — host-level, one file: name → which version. (The native-ESM equivalent is an import map.)
• remoteEntry.js — per remote: exposed modules → chunks.
• mf-manifest.json — per remote: build-generated metadata.

Where it lives: owned by the platform / host layer (not any single remote team — it's what decides which versions compose together). Common homes: a static file on the shell's own CDN, an edge KV store (Cloudflare KV, etc.) for instant global updates, or a small config / feature-flag service so version selection can even be per-user / per-region / A-B. The platform pipeline writes to it.

7“When would you NOT use micro-frontends?” — the question they'll ask

It's in the bank verbatim, so have the answer ready. Say no to MFEs when:

• Small/medium team (< ~50 engineers, one or few teams) — a monolith ships faster; MFE overhead is pure cost. [Bitovi]
• Performance is the top priority — MFEs add bytes and runtime cost; they don't remove them.
• Tightly-coupled, highly-shared UI — if every team touches the same components/state constantly, you'll fight the boundaries instead of benefiting from them.
• You lack the platform maturity — no CI/CD automation, no design-system enforcement, no observability → MFEs amplify the chaos.

And the pivot that scores points: “before micro-frontends, I'd reach for a monorepo” — you get shared code, atomic cross-cutting changes, and team boundaries without the runtime integration tax. That's §5.

8The often-better answer — monorepo (Nx / Turborepo)

A monorepo is many projects in one repo with shared tooling; a polyrepo is one repo per project. Crucial distinction the panel wants: monorepo is a build/source-organization choice; micro-frontend is a runtime-composition choice. They're orthogonal — you can have a monolith in a monorepo, or MFEs across polyrepos. Conflating them is a common junior tell.

The reason monorepos scale is the project graph + “affected” builds + caching. Nx/Turborepo diff Git, walk the dependency graph to find only the projects touched (and their dependents), and rebuild/test only those — cutting CI by up to 90%. Task inputs are hashed (source + config + env) into a cache key; identical inputs replay a cached result, and remote cache shares those hits across the whole team/CI. [Nx]

That module-boundary enforcement is the killer Lead point: in a monorepo you can codify architecture as a lint rule — tag libs (scope:checkout, type:ui) and fail CI if checkout imports admin, or a UI lib imports a data lib. You get team boundaries at build time, no runtime federation needed. [Nx]

9“Build a feature that touches multiple domains” — the design question

A classic Lead scenario: “Add a ‘Book with points’ promo that spans search, the property page, the cart, and the user wallet — how do you ship it across micro-frontends owned by four teams?” The senior move is to challenge the premise first, then show the mechanics.

1. Question the boundaries. A feature that touches every MFE is usually a signal the seams are wrong. Boundaries should follow business domains / vertical slices (Conway's law) so most features live inside one. If many features cut across, you've mis-drawn the seams — that's the finding, not the feature.
2. Name an owner. Cross-cutting work needs a single orchestrator — usually the host/shell, or a dedicated “experience” team. Diffuse ownership across four teams is how it stalls.
3. Compose, don't reach in. The host orchestrates; each domain exposes an explicit contract (props it accepts, events it emits). No MFE touches another's internal DOM or store. Types live in a shared contracts package.
4. Flag-gate the rollout. Remotes deploy independently, so you cannot ship the four changes atomically. Put the whole feature behind a feature flag that lights up only once all four remotes have shipped their piece — otherwise it half-renders in production.
5. Don't build a distributed transaction in the UI. Coordinating wallet-debit + booking across remotes belongs on the backend (one API/BFF), not orchestrated by browser events across four bundles.

10The Platform angle & Lead framing

This is exactly the rare shop where MFEs can be justified — huge org, many product teams (search, property, checkout, account, B2B). But the SEO/performance constraints push back hard: duplicated bundles hurt LCP, and runtime federation complicates SSR/streaming (Lessons 09–10). So the defensible Lead position is nuanced, not binary:

• Monorepo as the backbone — Nx/Turborepo, a shared design system + tokens as a local package, boundary lint to keep teams from reaching into each other's code. Atomic design-system upgrades across all teams in one PR.
• MFEs only at true deploy-independence seams — e.g. let the B2B partner portal or a legacy-migration slice deploy on its own cadence — and even then prefer server-side / SSR composition over client-side federation to protect SEO and first paint.
• Govern the shared deps — a single source of truth for React/design-system versions (renovate + a shared shared config) so version skew can't silently break a remote in production.

11Rapid-fire — other things the panel may probe

Short, confident answers to the adjacent questions that often follow. Each is one trade-off, not an essay.

12Check yourself — scenario quiz