Global CSS Leakage Without Encapsulation

When multiple teams deploy micro-frontends into a shared DOM, CSS isolation becomes a critical challenge. A ".button" class defined by Team A will override Team B's styles if both target the same selectors. Traditional solutions like CSS Modules or Block Element Modifier (BEM) naming conventions break down because autonomous teams cannot coordinate naming strategies. The root issue: the global nature of CSS combined with independent team deployments creates unpredictable style collisions that surface only in production integrations.

Shadow DOM provides true encapsulation by creating isolated style scopes, but introduces new problems. Global theming breaks because styles cannot penetrate the shadow boundary, and accessibility tools struggle with shadow-piercing. CSS-in-JS with generated unique class names solves collisions but adds runtime parsing overhead. Namespace prefixing enforces team boundaries through conventions, but scales poorly as teams grow and remains fragile under pressure.

Isolation Strategies and Trade-offs

Artifact: Table

Each strategy forces a choice between perfect isolation and practical functionality. Shadow DOM achieves encapsulation but fragments the styling system. CSS-in-JS maintains flexibility but penalizes performance. Convention-based approaches depend on human discipline rather than technical guarantees.

Shared Library Versioning Hell

Shared component libraries create hidden coupling across supposedly autonomous teams. When all micro-frontends import a common design system, updating the Button component requires synchronized deployments. This transforms independent teams into a distributed monolith where one change triggers cascading releases. The alternative allows each team to bundle their preferred version, resulting in visual inconsistencies and massive duplication. Loading five copies of the same component library wastes bandwidth and memory.

The versioning dilemma has no perfect solution. Forcing shared versions ensures consistency but destroys autonomy. Allowing version divergence preserves independence but fragments user experience. Most organizations cycle between these extremes before settling on hybrid models with versioned libraries and independent deployment windows that accept some inconsistency as the cost of team velocity.

Runtime Duplication Degrades Performance

Each micro-frontend loads its own framework runtime, creating multiplicative overhead. Five React-based micro-frontends can load five separate React instances unless Module Federation sharing is configured correctly. The network waterfall compounds the problem: the shell loads, fetches remote manifests, loads remotes, and each remote fetches its chunks. Users on slow connections experience fragmented progressive loading. Ironically, a well-optimized monolithic bundle with code-splitting often delivers faster perceived performance than distributed micro-frontends. The architecture's value lies in organizational benefits like team autonomy and independent deployments, not in technical performance gains.