A mobile client makes eleven requests to render one screen. What is the architectural problem, and what are the options?

The problem

Latency composes badly. Eleven sequential or partially-sequential requests on a mobile connection with a 150ms round trip is well over a second before anything can render, and the tail is worse: with eleven dependencies each occasionally slow, the screen is slow far more often than any individual call is.

It is also fragile — eleven opportunities for a failure — and expensive in battery and data.

The options

• A backend-for-frontend that aggregates. One request, the server fans out in parallel over a fast network, and returns a shaped payload. Usually the right answer for a mobile client, and its strongest additional benefit is that it absorbs backend changes and keeps the app's contract stable — which matters because a mobile app cannot be updated instantly.
• A query layer letting the client request the shape it needs, which avoids a deployable per client and introduces an unbounded query-cost surface that must be budgeted.
• Fewer, coarser endpoints designed for the screens that exist, which is simple and couples the API to the current UI.

What the aggregation must handle

• Partial failure. If recommendations fail, the screen should render without them rather than failing entirely. A deadline per component with a defined fallback is the mechanism, and it is what turns aggregation from a latency win into a resilience win.
• Independent cacheability, since the components have different freshness requirements and aggregating them into one response with one cache policy loses that.
• Not becoming a place for business logic. The BFF aggregates, shapes and adapts; it does not decide — logic there is logic duplicated per client, implemented differently each time.

The ownership question that determines success

The BFF should be owned by the client team, because its purpose is to serve that client's needs at that client's pace. One owned by a backend team becomes a queue — the client team requests changes and waits — which is the coupling the pattern existed to remove.