Micro-Frontend Architectures: Module Federation in Enterprise Portals

A host application owns routing, authentication, layout chrome, and the shared design system. Remotes expose mountable entry points and nothing else. The contract between them should be explicit and versioned: route ownership, the props a remote receives, the events it may emit, and the shared services it may call.

Communication between remotes should flow through the shell or a documented event bus. Direct remote-to-remote imports quietly recreate the monolith with worse tooling.

React and the design system should be shared singletons with strict version requirements. Two React copies produce hook errors; two design system copies produce duplicated CSS variables and inconsistent theming. Everything else can be shared loosely or bundled per remote.

Version skew is the dominant operational risk. Adopt a supported-range policy, run integration checks in CI that load every remote against the current host, and keep a rollback path per remote so one bad deployment does not require reverting the portal.

Federated portals load more network requests and often duplicate polyfills. Preload remote entry manifests for routes the user is likely to visit, and measure the total transferred bytes across the composed page rather than per remote — each team optimizing locally can still produce a slow portal.

Error isolation is essential. Wrap every remote mount in an error boundary that renders a scoped fallback, and tag telemetry with the remote name and version so a regression can be traced to a team within minutes rather than hours.