FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.13

Microfrontend

In one lineSplit the frontend by team ownership, compose at runtime, and pay for it in shared-dependency discipline.

Where you've seen itA retail site where the search team ships twice a day and the checkout team ships twice a month, independently.

  • Time20 min
  • DiagramShell + remotes composition, and the version-skew problem
  • Chapter11 · High Level Design

Diagram

diagram
1–2 · WHEN THIS IS THE RIGHT ANSWER

  in scope   independent deploys · team autonomy · gradual migration
  out        "it sounds modern" — that is not a reason
  scale      the honest threshold: 4+ teams, or a legacy app being
             strangled route by route

  Under 3 teams, a well-structured monorepo beats microfrontends
  on every axis. Say this out loud — it's a senior signal.
diagram
3 · RUNTIME COMPOSITION — shell plus remotes

  ┌──────────────────── Shell (host) ─────────────────────┐
  │  routing · auth · design tokens · shared layout       │
  │                                                       │
  │  ┌────────────┐  ┌────────────┐  ┌────────────────┐  │
  │  │  search    │  │   cart     │  │   checkout     │  │
  │  │  remote    │  │   remote   │  │   remote       │  │
  │  │  team A    │  │   team B   │  │   team C       │  │
  │  └────────────┘  └────────────┘  └────────────────┘  │
  │   own repo        own repo        own repo            │
  │   own deploy      own deploy      own deploy          │
  └───────────────────────────────────────────────────────┘

  Module Federation loads remotes at RUNTIME from their own URLs —
  the shell never rebuilds when a remote ships.
diagram
6a · DEEP DIVE — THE SHARED DEPENDENCY PROBLEM

  ✗ each remote bundles its own React
      3 remotes × 45KB = 135KB, plus TWO React instances
      → hooks break, context doesn't cross boundaries

  ✓ shared singletons declared by the shell
      shared: { react: { singleton: true, requiredVersion: '^18' } }
      → one instance, one copy, context works

  version skew is the recurring cost: team A wants React 19,
  teams B and C are on 18 → a coordinated upgrade, i.e. exactly
  the coupling microfrontends were supposed to remove.
diagram
6b · DEEP DIVE — COMMUNICATION BETWEEN REMOTES

  ✓ URL                      the best channel — shareable, debuggable
  ✓ custom events / event bus  loose coupling, typed contract
  ✓ shell-provided context     auth, locale, theme (one owner)
  ✗ shared global store        recreates the coupling you removed
  ✗ direct imports             remote A importing from remote B
                               destroys independent deployability

How it works

  1. Split by business domain and team, never by technical layer — "the checkout team", not "the components team".
  2. Shell owns routing, authentication, design tokens, and shared singletons.
  3. Remotes are independently built and deployed, loaded at runtime by URL.
  4. Contract-test the boundary so a remote's breaking change fails its own CI, not production.
  5. Budget performance centrally (4.5): three teams each adding "just 40KB" is how these sites get slow.

Trade-offs

GainCost
Independent deploysRuntime integration failures
Team autonomyDuplicate dependencies, version skew
Gradual legacy migrationMore infra: registry, versioning, CI per remote
Tech-stack freedom per teamInconsistent UX unless tokens are enforced

Interview angle

"Would you use microfrontends here?"

  • Only above roughly four teams, or to strangle a legacy app route by route — otherwise a monorepo with clear module boundaries gives the same isolation with none of the runtime risk.
  • If yes: shell owns routing, auth, and shared singletons; remotes deploy independently; communication goes through the URL and events, never a shared store.
  • The recurring cost is shared-dependency version skew, and I'd plan an upgrade cadence for it upfront.

Recap

  • Split by team and domain; compose at runtime through a shell.
  • Shared singletons are mandatory, and their versioning is the ongoing tax.
  • Recommending against microfrontends for a small team is the stronger answer.