Micro-Frontend
Splitting a web interface into independently developed and deployed pieces owned by different teams, composed at build time, server time or runtime.
The motivation is organisational rather than technical: a single frontend codebase owned by eight teams becomes a coordination bottleneck where every release requires everyone to be ready, and the slowest team sets the cadence.
Composition happens at one of three points, and the choice determines almost everything. Build-time composition through packages is simple and gives up independent deployment, which was the entire objective. Server-side composition assembles fragments per request and preserves both independent deployment and good initial load. Runtime composition in the browser, typically via module federation, gives the most independence and the most ways to fail.
The costs are consistently underestimated. Shared dependencies must be reconciled or duplicated, and duplicating a framework across five micro-frontends is a payload problem users feel. Visual consistency requires a design system with real discipline, or the product looks assembled from parts. Cross-fragment state and navigation need conventions that do not exist by default. And debugging spans several codebases with independent release cycles.
The threshold worth stating: micro-frontends are justified by team autonomy at a scale where coordination genuinely dominates, roughly five or more teams on one interface. Below that they import distributed-systems problems into the browser in exchange for a benefit nobody needed.