Overview

The Backends for Frontends (BFF) pattern is an improvement on the API Gateway pattern. Instead of having a single API Gateway service that serves different APIs for each type of client, the APIs for each client type are separated into individual API Gateway services.

Problem

A single API Gateway that serves multiple client types (mobile, desktop, third-party) can become a source of contention. Different teams responsible for different client applications need to coordinate changes to the same gateway. A failure in the gateway affects all clients simultaneously. Observing and scaling the gateway for different client traffic patterns is harder when everything is in a single service.

Solution

Instead of one API Gateway with different APIs for each client type, the BFF pattern creates a separate API Gateway service per client type. Each BFF is dedicated to one frontend (e.g., one for mobile, one for web, one for third-party APIs), implementing exactly the API that client type needs.

The separation of responsibilities becomes an advantage, as it allows greater independence and decoupling of services and the teams that maintain the Gateway APIs, following the "if you build it you own it" philosophy. The first significant applications of this approach were at SoundCloud, and organisations such as Netflix have been migrating towards it due to its advantages.

Trade-offs

Benefits

  • Greater independence and decoupling — different teams own different gateway services without coordination overhead
  • Greater reliability — a failure in one Gateway does not affect the others
  • Independent observability and scalability per client type
  • Each BFF can be optimised for the specific needs of its client

Drawbacks

  • More components to develop and maintain — one gateway service per client type instead of one shared gateway
  • Risk of duplicating cross-cutting concerns (authentication, logging) across gateways if not handled carefully

When to Use

Apply BFF when:

  • Multiple client types with very different API needs exist and are maintained by different teams
  • A single API Gateway is becoming a bottleneck or coordination point between teams
  • You want independent reliability, scalability, and observability per client type

Prefer a single API Gateway when:

  • There is only one type of client or the differences between clients are small
  • Team size and operational maturity do not justify maintaining multiple gateway services

References