Is Micro Frontend "Over-Engineering" or "Inevitable"?
Micro Frontends (MFE) have been both praised and criticized since their debut on the ThoughtWorks Technology Radar in 2018. They lost ground during the "monorepo + Turborepo" wave of 2022–2023, but since 2025 they have come back into the spotlight, driven by three tailwinds: the stabilization of Module Federation 2.0, the production-readiness of Rspack, and the growing productivity gap between teams accelerated by AI agents. This article surveys the current MFE technology stack as of April 2026 and walks through three phased migration case studies from major Japanese financial, SaaS, and e-commerce companies.
Module Federation 2.0: The Second Generation Matures
Module Federation was introduced in Webpack 5 in 2020 as a mechanism for dynamically loading modules from remote sources at runtime. Version 2.0, shaped significantly by contributions from the Rspack team at ByteDance, delivers a new API that works across both Webpack and Rspack. Three improvements stand out. First, a runtime plugin system makes it possible to dynamically rewrite the remote list and shared dependency versions at runtime, enabling A/B testing and user-segment-specific delivery without reloads. Second, type safety — 2.0 bundles `.d.ts` files in the remote container so IDE autocomplete works. Third, a Chrome DevTools extension ("Module Federation Inspector") provides real-time visualization of the loading graph.
Rspack / Vite / Webpack: The Build Tooling Front
Webpack 5 is increasingly the legacy option but remains the first choice for large existing projects due to its deep ecosystem. Rspack 1.x is a Rust-based Webpack-compatible builder — 5–10x faster — with official Module Federation 2.0 support, making it the standard for post-2025 greenfield projects. Vite 6 supports Module Federation via the `@module-federation/vite` plugin, but HMR and runtime resolution are still experimental in development. As of April 2026, Turbopack has not officially implemented Module Federation; staying on Webpack or Rspack is the realistic path for MFE today.
Single-SPA and iframes: The Other Routes
Single-SPA manages multiple SPAs through an application shell with lifecycle management — still the best option for organizations that need mixed frameworks (React + Vue + Angular). The 7.0 release in 2025 cut startup overhead by 40%. In practice, the most balanced approach is a hybrid of Module Federation + Single-SPA: Single-SPA handles mount control, Module Federation handles dependency sharing. This combination is used at Zalando, IKEA, and the Japanese case studies discussed below.
Edge Delivery and Cache Invalidation
The biggest operational challenge in MFE is keeping remote versions consistent. The 2026 best practice is Immutable Assets + Manifest Indirection. Remote JS chunks get content-hash-based filenames with `max-age=31536000, immutable` for long-lived caching; only the entry `mf-manifest.json` has a short TTL (max-age=60, stale-while-revalidate=300). The manifest acts as the indirection layer for version switching — update it and all hosts pick up the new version after the TTL expires.
Managing manifests in edge KV (Cloudflare, Fastly, CloudFront) has become standard. Canary deployments are achieved by adding a `traffic_split` field to the manifest and evaluating the percentage in the Module Federation 2.0 runtime plugin.
Case Study 1: Splitting a Major Bank's "Account Frontend"
A major bank's internet banking system split a monolithic React application (~2.4M LoC) into 7 MFEs by team. The triggers were classic monorepo pain: one team's change blocking six others' releases, 8-minute `npm install`, and 22-minute builds.
The chosen stack: Webpack + Module Federation 2.0 + Single-SPA. The host is a thin shell containing only account overview, navigation, and authentication, with 7 MFEs (Transfers, Investment Trusts, Loans, Cards, Tax Filing, Insurance, Support) loaded dynamically.
The 18-month phased migration started by extracting the shell first, wrapping the existing monolith as a single MFE via the "strangler facade" pattern. Individual features were then carved out from the monolith into separate MFEs. Each team gained the ability to upgrade React independently — at migration completion, React versions across MFEs ranged from 18 to 19.2.
Results were clear: average build time per team fell to 3 minutes (down 86% from 22), deployment frequency rose from once a week to an average of 12 times a day, and blast radius on incidents shrank from "all features down" to "affected MFE only." A bonus: independent deployment artifacts per MFE proved valuable for financial regulatory audit compliance.
Case Study 2: An HR Tech SaaS Running Rspack + Vite Side by Side
An HR Tech SaaS company runs its admin portal (Rspack) and employee self-service portal (Vite) with different build tools. The admin portal is large and requires IE11 compatibility for legacy customers; the employee portal is mobile-first and DX-driven — divergent requirements justified separate build tools.
Four features are shared across portals: common navigation bar, notification center, search, and help chat. Each lives in its own repo, built with Rspack, and loaded by both portals via Module Federation 2.0. The Vite side integrates as a remote consumer using the `@module-federation/vite` plugin.
Key lesson: "keep shared dependencies minimal." Initially many libraries — React, dayjs, Zustand — were marked as `shared`, which caused three production incidents from singleton conflicts. They eventually trimmed the list to just React, React-DOM, and the i18n context. Bundle size grew, but operational stability improved dramatically.
Case Study 3: An E-Commerce Platform's Edge Delivery Migration
A major e-commerce shop builder SaaS naturally aligns with MFE because it provides custom frontends per tenant. In 2025, they migrated to Rspack + Module Federation 2.0 with Cloudflare Workers dynamically generating an MFE manifest from the tenant ID. Rolling out new features to specific customers only or delivering holiday-specific designs per tenant became possible without engineer deployments. The pitfall was SEO: they solved it by pre-resolving the manifest in SSR and statically embedding structured data. Their index coverage rate improved from 92% to 98%.
Should You Adopt MFE? A Decision Checklist
If three or more of these apply, MFE deserves serious consideration: 5+ teams with independent release cycles / monorepo build times over 10 minutes / need to coexist different frameworks or framework versions / per-tenant customized delivery / want to limit blast radius to a single feature / need independent audit trails per feature. Conversely, if you have 1–2 teams, builds complete in under 3 minutes, and simplicity of first load is the top priority, MFE is overkill.
Conclusion: MFE in the Age of Rediscovery
With Module Federation 2.0 mature, Rspack production-ready, edge delivery advanced, and AI agents widening the gap between autonomous teams, MFE in 2026 has graduated from "technology for a few advanced organizations" to "the established pattern when conditions are right." The point isn't to adopt MFE as a universal solution — it's to adopt it as a targeted prescription for specific organizational pain and business requirements. As the three case studies here show, under the right conditions MFE delivers order-of-magnitude improvements in build time, release frequency, blast radius, and customization flexibility. Before dismissing it at your next architecture review as "old news," it's worth taking a fresh look at where your organization actually stands.