In a service-based architecture, a single product screen showing a user profile, recent orders, delivery status, and recommendations requires data from four separate services. Each service stores only its own data, so the caller issues four separate calls and merges the responses. This merging step is API composition.

The code that performs this merging can run in the mobile app, on a server, at a CDN edge, or inside one of the services. Putting a server between the app and services adds a network hop, but usually reduces total load time: a round trip between a phone and a server on a weak mobile connection can take a few hundred milliseconds, while a round trip between two services inside a datacenter takes a fraction of a millisecond. Trading four expensive round trips for one expensive round trip plus four cheap ones is often a large net saving.

Latency is only the first tradeoff. The merge location also determines behavior when a service is unavailable, caching possibilities, and which team must approve changes. This article dives deep into the API composition problem and patterns, covering client-side composition, over-fetching and under-fetching, composition/aggregation/orchestration, API gateways, Backends for Frontends, GraphQL as a composition layer, edge composition, availability and caching tradeoffs, versioning across multiple frontends, and ownership of the composition layer.