BFF vs API Gateway

The Backend for Frontend (BFF) pattern and API Gateway pattern both sit between clients and backend services, but they serve different purposes. An API gateway provides a single entry point for all clients. A BFF provides a dedicated backend tailored to each client type.

The Problem BFF Solves

When a web dashboard, mobile app, and IoT device all consume the same API gateway, compromises are inevitable. The mobile app gets fields it does not need (wasting bandwidth). The dashboard needs data from five services aggregated differently than the mobile app. The IoT device needs a completely different protocol.

BFF solves this by giving each client type its own backend that shapes data exactly as needed.

When to Combine Both

In practice, many architectures use both: an API gateway handles cross-cutting concerns (auth, rate limiting, TLS termination) at the edge, and BFFs sit behind the gateway to handle client-specific data aggregation and transformation.

This gives you centralized security and observability (from the gateway) with client-specific optimization (from BFFs).

The Duplication Problem

BFF's main drawback is logic duplication. If three BFFs all need to validate orders, you either duplicate the logic or extract a shared library — which creates coupling. The solution is to keep BFFs thin: they aggregate and transform data from downstream services but contain minimal business logic.

Explore our system design interview guide and API design interview questions for more patterns. See pricing for guided practice.

The Bottom Line

Use an API gateway when all clients need similar data and centralized cross-cutting concerns. Add BFFs when client experiences diverge significantly and frontend teams need autonomy to optimize their API layer.