Loading...
Loading...
Module Federation, Single-SPA, and when MFE beats a monolith — SDE-2 system design.
Micro-frontend architecture — Module Federation, Native Federation, Single-SPA, Web Components, iframes, team autonomy, and independent deployment.
Micro-frontend architecture: independently developed frontends composed into a whole — Module Federation, Native Federation, Single-SPA, Web Components, iframes, bounded contexts, independent deployment, shared state, CSS strategies, and cross-app communication.
Micro-frontends are a growing SDE-2 system design topic — interviews expect you to explain when MFE beats a monolith, how Module Federation works, and how teams share state without tight coupling.
This module covers all five integration approaches, Martin Fowler's common traits, architecture diagrams, when to use vs avoid MFE, and cross-app communication patterns.
Micro-frontends solve organizational scale, not small-app complexity — you will compare Module Federation vs Single-SPA vs Web Components, and learn how teams share dependencies and route between independently deployed apps.
Covers bounded contexts, independent CI/CD, CSS isolation strategies, bootstrap/mount/unmount lifecycles, cross-app events, shared React singletons, and 45 interview questions from architecture to deployment.
Micro-frontend questions appear in senior frontend and system design interviews. You must explain when MFE is worth the complexity, compare integration approaches, and describe how teams share state without creating a distributed monolith. The wrong answer is adopting MFE for a small team — interviewers want pragmatic trade-off thinking.
Independently developed frontends composed into a greater whole.
Micro-Frontend (MFE) is an architectural pattern where independently developed frontends are composed into a greater whole — analogous to microservices but for client-side single-page applications.
Break down complex UIs into smaller, independent components that can be developed, tested, and deployed autonomously. Each micro-frontend owns its bounded context: UI, data, state, business logic, and flow.
Problems with monoliths and benefits of decomposition.
Problems with monolithic frontend
| Problem | Description |
|---|---|
| Slow build times | Large codebase → minutes to build |
| Team coordination | Multiple teams blocking each other |
| Deployment bottlenecks | One change → full app redeploy |
| Technology lock-in | Can't upgrade framework without breaking everything |
| Cruft accumulation | Hard to refactor legacy code |
Benefits of micro-frontends
| Benefit | Impact |
|---|---|
| Independent deployment | Each team deploys without blocking others |
| Faster builds | Smaller repos → seconds to build |
| Technology flexibility | Use different frameworks (React, Vue, Angular) |
| Team autonomy | Cross-functional teams (backend → frontend) |
| Incremental upgrades | Upgrade one micro-frontend at a time |
| Reduced dependencies | Encapsulate business logic |
Martin Fowler's research on MFE characteristics.
| Trait | Description |
|---|---|
| Multiple independent elements | Structure similar to microservices modularization |
| Self-contained | Each MFE responsible for its bounded context |
| Bounded context | UI, data, state, business logic, flow (internally consistent) |
| Minimal sharing | Share as little business logic/data as possible |
| Clear interfaces | Sharing via custom events or reactive streams |
| Cross-functional teams | Same team works backend → frontend |
Five ways to compose independent frontends.
Webpack 5+ feature for runtime code splitting and sharing modules. Fast, framework agnostic, shared dependencies — but complex configuration and debugging.
// Host app new ModuleFederationPlugin({ name: "app", remotes: { sales: "sales@http://sales.com/remote.js", marketing: "marketing@http://marketing.com/remote.js", }, shared: { react: { singleton: true }, "react-dom": { singleton: true }, }, }); // Remote micro-frontend new ModuleFederationPlugin({ name: "sales", exposes: { "./Dashboard": "./src/Dashboard.jsx" }, });
ES modules and import maps — no Webpack required. Native browser support, simple configuration — less mature tooling.
<script type="importmap"> { "sales": "http://sales.com/app.js", "marketing": "http://marketing.com/app.js" } </script> <script type="module"> import salesApp from "sales"; import marketingApp from "marketing"; </script>
JavaScript library for MFE — framework agnostic, lifecycle management, routing integration. Additional dependency and learning curve.
import { registerApplication, start } from "single-spa"; registerApplication({ name: "sales", app: () => System.import("http://sales.com/app.js"), activeWhen: ["/sales"], }); registerApplication({ name: "marketing", app: () => System.import("http://marketing.com/app.js"), activeWhen: ["/marketing"], }); start();
Standard browser API — native support, framework agnostic, no build tool. Limited React event handling, state management complexity.
class SalesDashboard extends HTMLElement { constructor() { super(); this.attachShadow({ mode: "open" }); } connectedCallback() { this.shadowRoot.innerHTML = ` <div class="dashboard"> <h1>Sales Dashboard</h1> </div> `; } } customElements.define("sales-dashboard", SalesDashboard); // Host: <sales-dashboard></sales-dashboard>
Traditional HTML iframes — simple, complete isolation, no build tool. Poor performance, shared state difficult, navigation complexity, SEO issues.
<iframe src="http://sales.com/dashboard"></iframe> <iframe src="http://marketing.com/dashboard"></iframe>
Module Federation vs Native Federation vs Single-SPA vs Web Components vs Iframes.
| Approach | Performance | Complexity | Framework Support | Best For |
|---|---|---|---|---|
| Module Federation | High | Complex | All (Webpack) | Large enterprises |
| Native Federation | High | Simple | All (ESM) | Modern apps |
| Single-SPA | High | Medium | All | Multi-framework |
| Web Components | High | Medium | All | Standard compliance |
| Iframes | Low | Simple | All | Quick prototyping |
Host shell, independent MFEs, and shared dependencies.
┌─────────────────────────────────────────┐ │ Host Application │ │ (Shell / Router / Layout) │ │ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Sales │ │Marketing │ ... │ │ │ MFE │ │ MFE │ │ │ │(React) │ │(Vue) │ │ │ └──────────┘ └──────────┘ │ │ │ │ Shared: React, Redux, Design System │ └─────────────────────────────────────────┘
Good fit vs when to avoid MFE complexity.
Good fit when
| Criteria | Reason |
|---|---|
| Multiple teams | Scale with teams working on same project |
| Large codebase | Monolithic frontend is too complex |
| Decentralization | Empower teams to innovate |
| Technology diversity | Need different frameworks |
| Frequent releases | Fast delivery of increments |
Avoid when
| Criteria | Reason |
|---|---|
| Small team | 1–2 teams → monolith is simpler |
| Small app | No complexity → no need |
| Single framework | No technology diversity needed |
| Limited resources | MFE adds complexity |
What SDE-2 interviewers expect you to know.
Common interview questions about micro-frontends.