Design systems across micro-frontends

WHAT THIS TESTS This probes how independent deployability changes the constraints on a shared UI layer.

A GOOD ANSWER COVERS In a monolith, one version of the design system is bundled and consistency is easy. With micro-frontends, each app deploys independently and may pin a different design-system version, which creates two problems: visual and behavioral drift across apps, and runtime issues like multiple React copies or duplicated CSS. Technically, lean on runtime theming with CSS custom properties and design tokens so styling stays consistent even across versions, and share framework and design-system singletons through Module Federation, import maps, or a shared runtime scope to avoid duplicate instances. Distribution evolves from a simple npm dependency toward shared runtime modules plus published packages, with clear peer-dependency ranges. Governance must tighten: enforce supported version windows, deprecation timelines, automated adoption dashboards, and a policy for how far versions may diverge, since you can no longer rely on one bundle to keep everyone aligned.

COMMON WRONG ANSWERS Assuming nothing changes. Forcing every micro-frontend onto the exact same version, which defeats independent deployment. Ignoring duplicate React or CSS bloat. No story for runtime theming consistency.

LIKELY FOLLOW-UPS How do you avoid loading three versions of React? How do tokens help when versions differ? How do you keep visual consistency without lockstep upgrades?

ONE CONCRETE EXAMPLE Three micro-frontends share a host that exposes React and the design system as singletons via Module Federation. Each app pins a compatible version range. Theming flows through CSS variables sourced from tokens, so even if two apps run slightly different component versions, brand colors and spacing stay consistent. A dashboard tracks each app's design-system version.