Gateway Aggregation
Combining several backend calls into one client-facing response at the gateway, reducing client round trips at the cost of coupling the gateway to backend structure.
For a mobile client on a high-latency network, six sequential API calls is six round trips. Aggregation collapses them into one, and the latency saving is real and large.
The pattern is legitimate. The danger is where it lives.
Aggregation in a shared API gateway means the gateway now knows which services exist, what they return, and how to combine them. It becomes a place where change is required for every client feature, owned by a platform team, untestable in isolation, and on the critical path for every team's delivery. That is the distributed-monolith failure, and it starts with one reasonable aggregation.
The line: policy in the gateway, composition in a service. Authentication, rate limiting, TLS, routing, logging and protocol translation belong in the gateway. Anything that could break a business behaviour belongs somewhere with tests and an owner.
The BFF is that somewhere — one aggregating service per client type, owned by the team that owns the client. Composition is legitimate; it just needs an owner.
Two operational details for any aggregation: partial failure handling — decide per call whether a failure fails the response or returns a degraded one — and timeout budgeting, since the aggregate's timeout must accommodate the slowest call while remaining shorter than the client's.