Client-Specific Aggregation
A dedicated backend per client type that shapes and combines downstream data for that client's needs, owned by the client team.
The problem it solves: one API serving a web application, a mobile application and a partner integration ends up serving none of them well. Mobile needs fewer, smaller, coarser responses; web can afford more chattiness; partners need stability above all. A single API accumulates optional parameters, versioned response shapes and per-client conditionals until nobody can change it safely.
A backend-for-frontend gives each client a backend shaped for it. The decisive property is ownership: the client team owns its BFF, so client changes do not queue behind another team's priorities. That is what makes it different from an aggregation layer in the gateway.
Costs to weigh: duplicated logic across BFFs, which is acceptable for presentation shaping and a warning sign if business rules are being copied; more deployable units; and the risk that a BFF accumulates domain logic that belongs in a service.
Two alternatives worth naming rather than ignoring. GraphQL addresses the same problem by letting each client fetch what it needs from one schema — appropriate when clients are many and their needs diverge continuously, at the cost of real operational complexity. And where clients genuinely need the same data, one well-designed API is simpler than three BFFs.