A mobile screen makes six sequential API calls and takes two seconds on a good connection. What are your options?
Show the full answer Hide the answer
What is being tested
Whether you move aggregation to where round trips are cheap, and whether you know the trade-offs between the mechanisms.
The diagnosis
Six sequential round trips over a mobile network. Each is fast at the server and slow in aggregate, and no server-side optimisation helps — the time is in the network, repeated six times.
The options
1. Parallelise what can be parallel. The cheapest fix if the calls are independent: six parallel calls cost one round trip. Frequently they are not fully independent, but some are.
2. A backend for frontend. A thin backend, owned by the client team, that fans out to the six services inside the data centre — where a round trip costs a millisecond — and returns one shaped response.
This is usually the right answer, and the ownership matters: a BFF owned by a central team is the same bottleneck with an extra hop.
3. A query language, letting the client request exactly what it needs in one round trip. Solves over-fetching and round trips well; introduces query complexity, caching difficulty, and a real denial-of-service surface if depth and cost are not bounded.
4. A compound endpoint — conventional REST with an include parameter. Simple, cacheable, less
flexible. Frequently sufficient and under-used because the alternatives are more fashionable.
What the aggregating layer must do
- Fan out in parallel, with a per-call timeout inside an overall screen budget. Otherwise it aggregates the latency tails of six services and the slowest defines the experience.
- Degrade partially — render the screen without the failing section rather than failing the response. This is where the pattern adds real product value.
- Cache per client class, since payloads differ.
What to avoid
Endpoints named after screens, which couples the API to the interface and multiplies as screens do. Shape by what the client needs, not by where it is displayed.
Aggregation in the client, which is the current problem restated.
The general rule
Aggregation belongs close to the services, where round trips cost a millisecond — not across the user's mobile network, where they cost hundreds.