Fifty teams shipping frontend code independently sounds like a dream. Then React 17 and React 18 collide at runtime, your design system has six competing “latest” versions in production simultaneously, and a shared header owned by nobody quietly breaks for 30% of your users.
This is the real problem with micro frontends at scale. The pattern isn’t complicated. The governance layer — the shared kernel, versioning contracts, the theming system that can’t shatter when Team 47 deploys on a Friday — that’s where things fall apart. Here’s how to actually structure it.
At some point in a large enough frontend codebase, the build itself becomes the bottleneck. Thousands of components, dozens of teams, one monolithic bundle — something has to give. Module Federation is one of the more interesting solutions people have reached for, and it’s worth understanding properly before you commit to it.
What Is Module Federation? Module Federation is a feature introduced in Webpack 5 that lets JavaScript applications dynamically load code from other JavaScript applications at runtime — not at build time [1]. That single distinction is what makes it different from everything else.
Module Federation is one of those concepts everyone name-drops the moment “micro frontends” comes up in a meeting. Cool, share code at runtime, deploy teams independently, sounds great. Then someone on the team says “we’re on Vite, not webpack” and the whole conversation gets awkward. So what actually happens when you try to bring Module Federation into a Vite project? Some of it works beautifully. Some of it… really doesn’t, at least not yet.