Design micro frontends

Start with who needs what. Here the shoppers need one fast, consistent store and the engineers need to release without waiting for each other.

• Functional: one store that looks and behaves like one product; each team owns its pages and widgets end to end, from UI to the API it calls; the header and the cart count are shared across every page.
• Non-functional: a team releases and rolls back without the others; a broken piece doesn't take the page down; the product page stays inside its load-time and JavaScript budgets; the pieces look consistent; content is in the HTML for search engines.
• Scope cuts: how many teams (four here), whether pieces from different teams share one page (yes, on the product page), whether teams may pick their own framework (no), and whether a legacy app has to keep running alongside (not here).
• Architecture: a thin shell owned by the platform team handles routing, the header and the layout. Each team's micro frontend has its own repository or folder and pipeline and is deployed to its own versioned URL, and the shell keeps a manifest of which versions are live. Name the alternatives: one app, or a modular monolith that keeps one deploy.

Micro frontends fix one problem well: teams that block each other's releases. If that isn't your problem, they add cost and solve nothing. A senior answer argues from criteria, and the first question is how many teams there are.

• One team has nobody to release independently from. Keep one app with clear feature folders.
• Several teams that rarely collide do well with a modular monolith: packages with enforced boundaries and owners in one deploy, as in the monorepo case study.
• When releases block each other every week, or a legacy app must be replaced one route at a time, separate releases start paying for themselves. Then pick the lightest composition that fits: a route-level split when each team owns whole pages, and composition on one page only when pieces have to share a page.
• Count the cost before you commit: a platform team to own the shell and shared libraries, contracts between teams, more to monitor, and every extra framework loaded by every visitor.

Composition is where separately built pieces become one page, and it is the decision every later one depends on. You can compose at the router, at build time, on the server, at the edge, in the browser, or with iframes.

• A route-level split gives each team whole pages and never mixes them. It is the simplest form, and moving between teams' pages becomes a full page load.
• Build-time packages are easy, but the shell has to rebuild to ship a team's change. That brings back the shared release train you were trying to remove.
• Server and edge composition put every piece in the first HTML, which is good for search and first paint, but someone has to run the layer that stitches the fragments. On the server the page waits for the slowest fragment; at the edge, cached pieces arrive first and personalised ones follow.
• Client-side runtime composition (Module Federation, import maps) needs only static files and shares libraries well. The cost is a chain of requests before content appears. Iframes isolate everything, and you lose shared libraries, simple routing and easy accessibility.

Four teams that each bundle the framework would make every shopper download it four times. Runtime composition avoids that with a share scope: every piece registers the versions it brings, and the runtime decides which copy each piece uses.

• Module Federation picks the highest version in the scope that fits each piece's accepted range, which defaults to the range in its package.json. A piece that finds nothing compatible falls back to its own copy, so two versions end up on one page.
• Libraries that keep state, such as React, must be singleton: one copy for everyone. A piece whose range the singleton doesn't fit gets a console warning and runs on it anyway, or fails to load with strictVersion. A copy that has already loaded is never swapped for a higher version that registers later, so load order matters.
• Share subpaths too. Sharing react-dom without a trailing slash leaves react-dom/client bundled locally, which quietly loads a second React DOM.
• The design system is the other big shared dependency. Sharing more makes pages smaller and couples upgrades; sharing less frees each team and grows the page. A common setup shares the framework, router and design system as singletons and lets each piece bundle everything else. Roll out a design system major the way you would an API change: support the old and new versions for a while.

How pieces find each other and talk decides how coupled the teams really are. Keep the shared surface small and treat every part of it as a versioned contract.

• Routing is two-level. The shell maps top-level prefixes to pieces (/products to catalog, /cart to checkout) and each piece routes inside its prefix. Adding a section means one change to the shell's table; everything else stays inside a team.
• Prefer the URL for state that should survive a reload, and browser events for news between pieces (an item was added). Give events a team prefix, and have a piece read current state when it mounts, since it can't receive events fired before it loaded.
• Avoid a global store shared by every piece. It ties all teams to one state shape and one library version, and changing it becomes a coordinated release.
• Event payloads, props passed from the shell and URL parameters are APIs. Adding a field is safe. Renaming, removing or changing a field's type breaks every consumer still on the old shape, at runtime and with no compile error.

Independent release is the reason to adopt micro frontends, and containing failure is what makes it safe. Each piece should be able to go out, go wrong and come back without touching the others.

• Deploy each build to its own immutable, versioned URL and let the shell read a manifest of live versions. Releasing changes one manifest entry, and rolling back points it at the previous build, which is still on the CDN.
• Wrap every piece in an error boundary with a fallback, and give it a timeout, so a crash or a slow server costs one slot instead of the page. Keep the shell small and boring: nothing above it can catch its errors.
• Boundaries don't catch a broken contract, because the page renders with wrong data. That needs contract tests before release and monitoring of errors and key numbers per piece after it.
• Roll out gradually: send a share of users to the new version through the manifest and watch that piece's errors before going to everyone. The catch is that two versions run at once, so contracts must work with both.

Style collisions are easy to ship when teams release separately. Two teams write .title, the one that loads last wins, and the header changes when checkout deploys.

• A team prefix on every class (checkout-title) is cheap and works if everyone follows it. Scoped class names, generated by CSS Modules and similar tools, do the same automatically. Neither stops element selectors such as button from leaking.
• A shadow tree blocks selectors in both directions. Inherited properties (font, color) and CSS custom properties still cross the boundary, so theme tokens reach every piece. The cost is that global styles, including the design system's, don't; each shadow root has to load them itself.
• Consistency comes from one design system with shared tokens for color, spacing and type, owned by the platform team and loaded once. It should hold UI only, never business logic.