Backend for Frontend (BFF) Pattern: Tailored APIs per Client, Visualized

The Backend for Frontend (BFF) pattern is an architecture in which you build a separate, dedicated backend service for each type of frontend — one for web, one for mobile, one for IoT — instead of forcing every client to share a single general-purpose API. Each BFF sits between its client and the downstream microservices, aggregating and reshaping data so the frontend receives exactly the payload it needs and nothing it doesn't.

In a microservices system, the data a screen needs is rarely owned by a single service. A product page might pull from a catalog service, a pricing service, a reviews service, and an inventory service. The question is who stitches those calls together. The BFF pattern answers: a thin server-side layer owned by the frontend team, tuned to one client's exact requirements.

A single shared API has to be a compromise. A desktop web client on fibre can happily render a fat JSON blob with fifty fields and nested relationships. A mobile client on a flaky cellular connection wants a slim payload, fewer round trips, and battery-friendly behaviour. An IoT device or smart TV might only need three fields and can barely parse a large response at all. When one API serves all of them, it ends up over-serving the constrained clients and under-serving the rich ones.

The friction is real: every time the mobile team needs a field trimmed or two calls merged, they have to negotiate with whoever owns the shared API — a team juggling the needs of every other client at once. Versioning becomes painful, because a change for mobile risks breaking web. The shared API slowly accretes client-specific flags and query parameters until it serves everyone badly. A BFF cuts that knot by giving each frontend a backend it fully controls.

The core move is one BFF per experience, not per microservice. The web app talks only to the Web BFF; the mobile app talks only to the Mobile BFF; an IoT or TV experience gets its own. Each BFF is free to expose whatever shape, endpoints, and protocol best suit its client, while the downstream microservices stay generic and stable. The animation below shows three clients each hitting their own BFF, which fans out to the same shared microservices and returns a tailored response.

Without a BFF, a client often has to make many calls to render one screen — fetch the product, then its price, then its reviews, then stock — each a separate round trip over a high-latency mobile link. This is the chatty client problem. A BFF performs request aggregation: the client makes one call, and the BFF fans out to the downstream services in parallel, waits for them, and composes a single response. Round trips over the slow network drop from many to one.

Aggregation in a BFF is usually just parallel fan-out with a join. A small Node.js handler makes that concrete:

Aggregation merges calls; payload shaping decides what comes back. A microservice's natural response is verbose — internal IDs, audit timestamps, nested objects, fields no UI renders. The BFF projects that down to precisely what one screen needs. The Mobile BFF might return six fields where the Web BFF returns thirty. It can rename fields to match the client's models, flatten nested structures, pre-format dates and currency, and drop everything irrelevant — shrinking bytes on the wire and CPU spent parsing on a constrained device.

When the client orchestrates — calling service A, using its result to call B, retrying C, handling partial failures — that logic gets duplicated across iOS, Android, and web, and it ships inside an app you can't easily update once it's on a user's phone. A BFF pulls orchestration to the server. Call sequencing, retries, timeouts, fallbacks, and the "if reviews fail, render the page anyway" rules live in one deployable service that you can fix without an app-store release. The client becomes a thin renderer of whatever the BFF returns.

BFFs and API gateways are often confused because both sit between clients and microservices. An API gateway is a single, generic entry point handling cross-cutting concerns — authentication, rate limiting, TLS termination, routing — the same way for everyone. A BFF is client-specific: it knows about screens and use cases and exists to aggregate and shape data for one frontend. They are complementary. A common topology is a shared gateway in front of several BFFs: the gateway does auth and rate limiting, then routes to the Web BFF or Mobile BFF, each of which composes its own tailored response.

BFFs are not free. Code duplication is the headline cost — the Web and Mobile BFFs often need similar aggregation logic, and naive copy-paste drifts out of sync; teams usually extract shared pieces into libraries while keeping the client-specific shaping separate. You also have more services to deploy, monitor, secure, and keep available, and each BFF is another network hop and another potential point of failure. For a small team with a single client, or an internal tool, a BFF is over-engineering — the pattern earns its keep once you have multiple genuinely different frontends over a fan-out of microservices.

The pattern was popularized at SoundCloud — the term "Backend for Frontend" is widely credited to Phil Calçado and the SoundCloud team as they broke up a monolith and needed per-client edge services. Netflix independently pushed a similar idea hard, building device-specific adapters at the edge so hundreds of device types — phones, TVs, consoles, browsers — each get a response tuned to their constraints rather than one universal API. Today BFFs are standard practice across companies running rich microservice backends behind multiple distinct frontends.

No. An API gateway is a single generic entry point that handles cross-cutting concerns like auth and rate limiting uniformly for every client. A BFF is client-specific and exists to aggregate and shape data for one frontend. They're complementary — a gateway often sits in front of several BFFs, doing auth and routing before each BFF composes its tailored response.

One per distinct frontend experience, not one per microservice. Typically that means a Web BFF, a Mobile BFF, and perhaps an IoT or partner BFF. If two clients have nearly identical needs, share a single BFF — don't split until their requirements actually diverge, since each BFF adds deployment and maintenance overhead.

They overlap but aren't identical. GraphQL lets the client select fields and aggregate across resolvers, solving over-fetching and chatty calls from the client side. A BFF solves the same problems server-side with full freedom over protocol, caching, and orchestration. Many teams combine them — a per-client GraphQL endpoint is effectively a BFF whose query language is GraphQL.