Runtime Composition
Assembling one page from independently deployed fragments at request or render time, which is what makes micro-frontends more than separate builds.
The promise of micro-frontends is independent deployment: a team ships its part without coordinating a release with five others. That only holds if composition happens at runtime. Composing at build time means a change to any fragment requires rebuilding and redeploying the shell, which is the coordination the architecture was meant to remove.
Runtime composition has three common forms — server-side inclusion of fragments, edge-side assembly, and client-side loading of remote modules — and each has to answer the same questions: what happens when a fragment fails to load, how is a slow fragment prevented from blocking the page, and what does the user see in the interim.
The cost that is consistently underestimated is the shared runtime. Fragments share one DOM, one set of global styles, one router, one authentication state and often one framework instance. Two fragments on different major versions of the same framework either both ship it — doubling the bundle — or one is constrained by the other's upgrade schedule, which is precisely the coupling that was supposed to have been removed.
The honest test before adopting it is whether the teams genuinely cannot release together. If they can, a modular monolith delivers most of the benefit with none of this.