What is the API Composition pattern for querying data across services?

The API Composition pattern implements a query that requires data from multiple microservices by having an API composer — typically the API gateway, a BFF, or a dedicated aggregation service — call each relevant service in parallel, then join and transform the results in memory before returning a single response to the caller. It replaces the cross-service SQL JOIN that becomes impossible when each service owns its own database.

For example, a "Get Order Details" screen needs data from three services: Order Service (order status, items, timestamps), Customer Service (name, shipping address), and Product Service (product names, images). The composer calls all three — ideally in parallel — and merges the results into one response document.

The approach works well when:

• The amount of data being joined is manageable in memory (hundreds to low thousands of records).
• Queries do not require complex aggregations such as GROUP BY, SUM, or window functions across large datasets.
• Response-time SLAs are met even after adding the latency of parallel service calls.

Limitations of API Composition:

• No transactional consistency — data is fetched from multiple services at different instants, so results may reflect slightly different states.
• Scalability — joining large datasets (e.g., all orders in the last year with full customer profiles) in memory is expensive and may exhaust the composer's heap.
• Complexity — partial failures (one service is down) must be handled gracefully; the composer must decide whether to return partial results or fail the request.

For queries that are too complex or too large for in-memory joining, the CQRS pattern (Q12) with a pre-built, denormalised read model is the preferred alternative.