# API Composition

> Fan out to multiple services, join results in-memory — no shared DB needed.

- **Category**: Microservices
- **Subcategory**: API Design
- **Canonical URL**: https://designpattern.fyi/patterns/api_composition/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Product detail page that pulls inventory from Service A, pricing from Service B, and reviews from Service C — composer fetches all three and returns one clean response.





## Trade-offs


### Advantages

- No cross-service DB coupling — services stay independent

- Easy to reason about data ownership

- Parallelizable calls = lower latency when done right

- Simple mental model — just an orchestrated fetch




### Considerations & Drawbacks

- In-memory joins can get heavy with large datasets

- Composer becomes a bottleneck / single point of failure if not scaled

- Doesn't work well for complex filtering or aggregations (use CQRS instead)

- Error handling across multiple calls adds complexity







---
**Reference**: [Original Source](https://microservices.io/patterns/data/api-composition.html)