Module federation lets teams share components at runtime rather than through published packages. What does that buy and what does it cost?

What it buys

• Updates without a consumer rebuild. A shared component change reaches every consumer on their next page load, which matters when consumers number in the dozens and coordinating rebuilds is slow.
• Deduplicated shared dependencies at runtime, avoiding the multiple-framework-copy problem that independently built micro-frontends otherwise have.
• Independent deployment with genuine composition rather than iframe isolation.

What it costs

• Failures move from build time to runtime. A version incompatibility that a package manager would catch during a build now surfaces in a user's browser, on a device you cannot inspect, potentially only for some users.
• Testing gets harder. What is tested is one combination of versions; what runs is whatever combination happens to be deployed. The combination space grows with the number of federated modules.
• Rollback is not local. Reverting the shared module reverts it for everyone, so a fix for one consumer's breakage removes a feature others depend on.
• A runtime loading dependency. A shared module that fails to load breaks the consumers that need it, which requires fallback handling that is easy to omit.

The determining question

How often do shared components change, and how expensive is a coordinated rebuild? Frequent changes with many slow-to-rebuild consumers favour runtime sharing. Infrequent changes, or fast builds, make published packages the better trade — the failures are caught at build time, which is where failures are cheapest.

The mitigation that makes it survivable

Strict version contracts on shared modules, plus integration tests against the actually-deployed combinations, plus a fallback for load failure. Runtime composition without those is a distributed system with no failure handling, and it will behave like one.