Composite Application Pattern
A composite application assembles independent capabilities into a user-facing experience through composition rather than a monolith, so each capability can be built, deployed, and evolved by a.
Definition
A composite application is an architecture where the user experience is assembled at runtime from independently developed and deployed capability units — through server-side composition, edge composition, or client-side composition — so that each unit is owned by one team and the experience is a composition rather than a monolith.
Context and scope
Applied in enterprise portals, micro-frontends, and any large product where a single team cannot own the entire UI and independent deployment is required.
Common misconceptions
- Composite applications are just micro-frontends — micro-frontend is one composition style; composite application is the broader pattern that includes server-side and edge composition
- Composition always means client-side assembly — server-side and edge composition can assemble the experience without client-side orchestration
Anti-patterns
- Composing at runtime without a shared design system, producing an experience that looks like three apps stitched together
- Letting one capability unit block the whole page on a slow response, instead of composing with fallbacks
Related concepts
Authoritative source
What it is
A composite application is an architecture where the user experience is assembled at runtime from independently developed and deployed capability units — through server-side composition, edge composition, or client-side composition — so that each unit is owned by one team and the experience is a composition rather than a monolith. Applied in enterprise portals, micro-frontends, and any large product where a single team cannot own the entire UI and independent deployment is required. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.