What you'll learn
Quick Answer
The Backend for Frontend (BFF) pattern gives each type of client — web, iOS, Android, a partner API — its own dedicated backend service, shaped around exactly what that client needs, instead of every client sharing one general-purpose API. It was named by Sam Newman after a pattern SoundCloud's engineers, credited to Phil Calçado, had already built out of necessity around 2011-2013 while breaking up a monolith. It's a different tool from an API Gateway: a gateway is one shared front door for cross-cutting concerns, while a BFF is a separate backend per client, often owned by that client's own team.
The Problem: One Backend Trying to Please Every Client
A single, general-purpose API trying to serve a web app, a mobile app, and maybe a partner integration or a smart TV app ends up in an uncomfortable spot. The mobile team wants a small, aggregated payload to save battery and mobile data. The web team can afford a richer, more granular response because bandwidth and rendering budget are less constrained. A partner integration wants something else again — usually something more stable and explicitly versioned. One shared endpoint trying to satisfy all three either over-fetches for whoever needed less, under-fetches for whoever needed more, or slowly grows a pile of conditional query parameters (?fields=, ?platform=, ?include=) until the response shape becomes a negotiation nobody on any team can fully reason about anymore.
The deeper cost isn't the payload shape at all — it's coordination. Every UI change that needs slightly different data now has to go through whichever team owns the shared backend, competing for priority against every other client's requests. That's precisely the kind of cross-team dependency that microservice-oriented architectures are trying to remove in the first place, and a single shared API tends to quietly reintroduce it.
What a BFF Actually Is, and Where the Name Came From
Instead of one shared backend, each client type gets its own dedicated backend service — a web BFF, an iOS BFF, an Android BFF, a partner-API BFF — each one calling into the same underlying domain services, but aggregating, filtering, and shaping the response differently for the one specific client it exists to serve.
The pattern's origin is well documented and worth knowing precisely, because it wasn't invented as an abstract idea first. It emerged at SoundCloud around 2011-2013, while the company was breaking apart a monolith, and is credited to then-SoundCloud engineer Phil Calçado, who coined the term for what teams there had already converged on independently. Sam Newman later named and formally wrote the pattern up — in his "Backends For Frontends" pattern write-up and in his book Building Microservices — turning a solution one company had built out of necessity into a repeatable pattern the rest of the industry could recognize and reach for deliberately.
BFF vs. API Gateway: Related, Not the Same
This blog already covers the API Gateway pattern in depth, so the contrast here is deliberately brief. An API Gateway is typically one shared entry point in front of every client and every backend service, handling cross-cutting concerns — authentication, rate limiting, TLS termination, routing requests to the right service — the same way regardless of who's calling.
A BFF addresses the opposite axis of a related problem. Instead of one gateway serving every client identically, you deliberately run multiple backends, each serving exactly one client type differently. The two aren't mutually exclusive, and in practice they're often combined: an API Gateway sits in front of a set of BFFs, handling the shared infrastructure concerns, while each BFF behind it handles one specific client's shaping and aggregation logic.
What a BFF Actually Does, Concretely
Aggregation is the most common job. A mobile app's home screen might need data from five different backend services — user profile, recent activity, recommendations, a notifications count, a promo banner. Instead of the mobile app making five separate round trips over a mobile network (slow and battery-expensive) or a shared API awkwardly bolting all five together for every client whether they need it or not, the mobile BFF makes those five internal calls itself and returns one response shaped exactly like the screen that's about to render it.
A BFF also absorbs client-specific logic that has no real business living inside a shared domain service: field renaming or formatting a particular client's UI expects, trimming a response for a bandwidth-constrained client, or handling an authentication flow that looks nothing like another client's — a partner integration's OAuth flow, for instance, versus a mobile app's plain session token.
It also hides internal topology. The mobile app never needs to know it's ultimately calling five separate microservices behind the scenes — it talks to its own BFF, and how many underlying services exist, how they're versioned, and how they're organized is entirely the concern of the BFF and the platform team behind it.
Who Owns It, and the Real Cost of Multiple Backends
The usual ownership model is also the actual point of the pattern: the team building the mobile app owns the mobile BFF, and the team building the web app owns the web BFF. A UI change that needs a slightly different aggregation doesn't require filing a request against a separate backend team and waiting in their queue — the frontend team owns the full vertical slice for their own client and can change their BFF and ship on their own timeline.
That autonomy has a real, non-hypothetical cost. Three BFFs plus the underlying domain services is genuinely more services to build, deploy, and operate than one shared API. And without deliberate discipline about where logic lives, similar aggregation code gets duplicated across BFFs instead of consolidated in one place — a real maintenance burden that shows up the first time a shared business rule needs to change in three places instead of one.
When a BFF Is Overkill
If you only have one client — a single web app, say — or two nearly identical ones, a BFF adds a whole extra service and deployment pipeline for a coordination problem you don't actually have yet. A shared API is simpler, and it's the right call right up until client needs genuinely diverge enough to justify splitting.
Small teams in particular feel the ownership benefit less and the operational cost more, because there's no separate frontend team waiting on a separate backend team to begin with. The pattern earns its complexity once you have multiple, meaningfully different client types being built by genuinely separate teams — which is the exact situation it was invented to solve at SoundCloud in the first place, not a general best practice to apply by default.