A travel platform serves web, iOS, Android and partner integrations from the same services. When is a backend-for-frontend justified?

The problem a BFF solves

Different clients need genuinely different data shapes. A mobile screen needs a compact payload assembled from six services; the web equivalent shows more; a partner needs a stable contract that changes slowly. Serving all of them from one API produces either an over-fetching payload sized for the largest consumer or a proliferation of query parameters that make the API impossible to evolve.

A BFF gives each client an interface shaped for it, owned by the team that owns that client, with aggregation and trimming happening server-side where the network is fast.

When it is justified

• Client needs have genuinely diverged, not merely differ in presentation.
• Aggregation is expensive over the client's network, so six mobile round-trips become one.
• Client teams can own their BFF. A BFF owned by a central team is another queue, and it inherits all the coordination cost it was meant to remove.
• The number of clients is small. One per platform is manageable; one per screen is not.

What it costs

Another deployable per client, with its own pipeline, monitoring and on-call. Duplicated logic across BFFs, which drifts — the same field computed slightly differently in the iOS and Android BFF is a real and common bug class. And an extra hop, adding latency and a failure point.

The alternative worth considering first

A query language letting clients request the shape they need removes much of the motivation, at the cost of query complexity, caching difficulty and a genuine risk of expensive client-authored queries reaching the backend. It trades a per-client server for a per-query governance problem.

Neither is free. The BFF moves complexity to a place each team controls; the query layer moves it to a place the platform must govern.