Micro-frontend orchestration
Slap yourself if
You think micro-frontends fail because teams didn’t ‘coordinate enough’.
Why this exists
Micro-frontend orchestration exists because splitting a UI into independently owned pieces does not magically make them compose. Once multiple runtimes, bundles, and release cadences meet on one screen, something has to decide who loads, who renders, and who owns shared concerns.
Mental model
Micro-frontends are not components — they are semi-autonomous applications. Orchestration is the control plane that arbitrates lifecycle, ownership, and integration when no single app is in charge.
- Multiple independently built frontends are loaded into the same runtime.
- An orchestrator decides when each app mounts, updates, or unmounts.
- Shared resources like routing, state, and CSS become contested.
- Failures are isolated only if the orchestration layer enforces boundaries.
- Implicit coupling through global state or DOM assumptions.
- Routing conflicts between independently shipped apps.
- CSS and style leakage across boundaries.
- Assuming module federation equals orchestration.
Micro-frontend orchestration is the layer responsible for coordinating lifecycle, routing, and shared concerns across independently deployed frontend applications running in the same UI surface.
- Multiple apps touching window or document directly
- Shared global stores without ownership rules
- CSS namespaces treated as optional
- No defined mount or teardown contracts
Deep dive
Premium deep dives include more internals, more scars.