Multiple teams own different parts of the UI (e.g. header, search, checkout). Each part is a separate app: its own repo, build, and deploy. A shell (or host) composes them into one page at runtime.

Benefits: teams ship independently, use different stacks if needed, and scale ownership. Trade-offs: consistency (design, auth, routing) and operational complexity (versioning, contracts, performance).

Build-time: merge multiple repos into one bundle at build; simpler integration but coupled releases and shared dependency versions.

Runtime: the shell loads fragments at runtime—via iframe, script tags, or Web Components. Each fragment is deployed independently. Module Federation (Webpack), single-spa, or a custom loader can orchestrate this. You need clear contracts (props, events, URLs) between shell and fragments.

The shell usually owns the URL and top-level routing; it tells each fragment which “route” or context it is in. Shared state (user, theme) can be passed as props, via a small shared library, or through a global event bus—keep the surface small.

Design consistency is hard when each team owns its UI. Shared design tokens, a base component library, or a design system that all teams consume helps. Document patterns and avoid duplicate implementations of the same pattern.

Micro-frontends make sense when you have many teams that need to ship their part of the product independently, or when you are gradually breaking a monolith into team-sized pieces. They are usually not worth it for small teams or simple products.

[Building Micro-Frontends](https://www.oreilly.com/library/view/building-micro-frontends/9781492082996/) (Luca Mezzalira, O'Reilly) covers integration patterns, deployment, and scaling frontend ownership.