Design systems across micro-frontends
adapting a design system to independently deployed front ends.
shared singletons and version alignment, token-based theming, distribution via shared scopes, stronger governance.
What's really being asked
This probes how independent deployability changes the constraints on a shared UI layer.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Why does moving to micro-frontends complicate keeping a design system visually consistent compared to a monolith?
- a.All micro-frontends must share one bundle by definition
- b.Each app deploys independently and may run a different design-system versionCorrect
- c.Design tokens stop working outside a monolith
- d.Micro-frontends cannot use CSS variables at all
Why? this is the answer
Independent deployment means apps can pin different versions, causing drift and duplicate dependencies. Runtime theming via CSS variables and tokens actually helps here, and micro-frontends specifically avoid sharing a single bundle.
Just read this? Test yourself on what you have been reading.
Read the original → stevekinney.com
- #micro-frontends
- #architecture
- #distribution
- #module-federation
- #governance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles