What is Angular micro-frontend architecture?

Micro-frontends extend microservices principles to the frontend — splitting a large Angular application into independently developed, deployed, and released frontend pieces. Module Federation (Webpack 5): the most common Angular micro-frontend implementation. Each micro-app exposes its own Angular components/modules as remote entries. The shell app loads them at runtime. // webpack.config.js in remote app: new ModuleFederationPlugin({ name: "checkoutApp", filename: "remoteEntry.js", exposes: { "./CheckoutModule": "./src/app/checkout/checkout.module.ts" } }). Shell app: { path: "checkout", loadChildren: () => loadRemoteModule({ type: "module", remoteEntry: "https://checkout.example.com/remoteEntry.js", exposedModule: "./CheckoutModule" }).then(m => m.CheckoutModule) }. Nx with Module Federation: nx g @nx/angular:remote checkout --host=shell — generates the Module Federation configuration automatically. Challenges: (1) Shared dependencies (multiple Angular versions = large bundles); (2) Communication between micro-frontends (shared state, custom events, URL); (3) Routing coordination; (4) Style isolation (CSS-in-JS or strict naming); (5) Testing (integration tests span boundaries). Alternatives to Module Federation: iframes (maximum isolation, awkward UX), web components (framework-agnostic), single-spa (meta-framework, supports multiple frameworks). When to use: large org with many teams deploying independently; different technology stacks needed; regulatory boundaries between teams. Cost: high complexity — don't use unless the team/org size genuinely requires it.