Subsystem 01
Shell / host container
Root layout, authentication provider, global navigation and routing
Typical stack
Next.js / webpack host shell
Reference architecture
Micro-frontend architecture with Module Federation
Let separate frontend teams deploy independently into one customer portal, with shared dependencies loaded once and a single sign-in.
Design constraints
What the design has to hold to
Targets for the scenario this reference is sized for. A real engagement starts by replacing them with your own numbers.
- 01Independent deployment pipelines for each frontend team
- 02Shared runtime dependencies (React, design tokens) loaded only once
- 03One authentication context and global navigation across every micro-app
- 04Initial portal load under a second on desktop broadband, with CLS below 0.05
Component topology
System components and technologies
Subsystems with separate responsibilities, clear contracts between them and storage that scales on its own. The stack named for each is typical, not mandatory.
Stack topology
Micro-frontend architecture with Module Federation
Illustrative reference architecture
- 01
Shell / host container
Root layout, authentication provider, global navigation and routing
Next.js / webpack host shell
- 02
Remote sub-applications
Feature micro-apps (billing, analytics, user management) deployed independently
Module Federation 2.0
- 03
Shared design system
Version-locked UI component library distributed through npm
Tailwind CSS + Radix UI
- 04
Event bus & state bridge
Cross-app communication without tight runtime coupling
Custom event bus (RxJS / window events)
Subsystem 02
Remote sub-applications
Feature micro-apps (billing, analytics, user management) deployed independently
Typical stack
Module Federation 2.0
Subsystem 03
Shared design system
Version-locked UI component library distributed through npm
Typical stack
Tailwind CSS + Radix UI
Subsystem 04
Event bus & state bridge
Cross-app communication without tight runtime coupling
Typical stack
Custom event bus (RxJS / window events)
Data lifecycle
End-to-end data flow
The user opens the portal; the host shell loads and verifies their authentication token.
The router reads the path (/analytics) and imports the analytics remote module from the CDN.
Module Federation resolves shared dependencies (React 19, Tailwind tokens) to the host's singletons.
The remote renders inside the host layout and inherits the authenticated user context.
Micro-apps announce global state changes, such as a workspace switch, on the event bus.
Reliability and resilience
Failure modes and how each is contained
Failure mode 01
A remote fails to deploy or load
Mitigation
Wrap every remote import in a React error boundary with fallback UI.
Failure mode 02
Shared dependency version mismatches
Mitigation
Strict singleton and requiredVersion rules in the Module Federation config.
Failure mode 03
CSS class name collisions
Mitigation
Per-app Tailwind prefixes (tw-billing-) or CSS Modules, so one app's styles can't override another's.
Questions
What teams ask about this design
When several frontend teams, often 30 or more engineers, block each other's releases in a single codebase. Below that, a well-structured monorepo is usually simpler.
They can: duplicated libraries bloat bundles. With shared singletons and route-level code splitting the overhead is small, and we check bundle size per route to confirm it.
Planning a system like this?
Send us your requirements, expected load and budget. We'll reply within one business day with an honest read on the design, and on whether we're the right team to build it.