Cards/APIsSystem Design · Day 83Oct 24, 2026

One API, Three Unhappy Clients

A mobile app discarding thirty-six of forty fields from a shared API, and a backend-for-frontend layer per client that collapses five round trips into one

The mobile app needs four fields. The web app needs forty. The watch needs two. One shared API serves all three, so it returns forty, and the phone discards thirty-six of them over a patchy network.

Worse than the wasted bytes is the politics. Every improvement one client wants gets negotiated with two other clients who do not want it.

A backend-for-frontend gives each client its own thin API layer, owned by the client team. It calls the same shared services as everyone else, aggregates across them, and trims the response for exactly one consumer. No business logic lives there — that stays in the services.

The win compounds on latency. A screen that needed five round trips from the phone becomes a single call to its own BFF, which fans out server-side where the network is fast and reliable.

The cost is duplicated aggregation logic, more services to build and deploy and operate, and consistency that now has to be managed across several layers rather than enforced in one.

When one thing must satisfy everyone, it ends up serving no one particularly well — and nobody is free to improve it.

When one thing must satisfy everyone, it ends up serving no one particularly well — and nobody is free to improve it.