What are the main limitations of the API composition pattern, and what do teams usually reach for once they hit them?

API composition struggles with three specific things: sorting or filtering a combined result across services, since you can't ask a database to sort data it never had in the first place, forcing that work into slow, memory-heavy application code; a response time permanently capped by the slowest single downstream dependency, no matter how well the concurrent calls are implemented; and partial failures, where one downstream service being unreachable forces an awkward decision about what an incomplete response should even look like. Once a system genuinely runs into these limits — needing fast, flexible, cross-service queries at real scale — teams typically move toward CQRS with a purpose-built, pre-aggregated read model instead of assembling the same data fresh on every single request.