How does a Backend-for-Frontend pattern differ from a single shared API gateway serving all client types, and what's a concrete case where the shared-gateway approach breaks down?
answer
- gateway = cross-cutting infra, uniform surface
- BFF = per-client shape, owned by client team
- can layer both: gateway in front of BFFs
- gateway becomes a bottleneck when clients diverge
- converged BFFs are a signal to consolidate
basics
~20 sA shared gateway is one door for every app; a BFF is a separate, tailored door per app. The shared-gateway approach breaks down when different apps need very different data shapes and change at different speeds, because now every client's feature work has to queue behind the one team that owns the shared door.
solid answer
~50 sA generic API gateway centralizes cross-cutting concerns - routing, authentication, TLS termination, rate limiting - and typically exposes a fairly uniform API surface to every client, usually owned by one central team. A BFF instead gives each client its own tailored API, owned by that client's own team, focused on aggregation and view-shaping rather than infrastructure. The shared-gateway approach breaks down when web, mobile, and a partner integration all need meaningfully different response shapes and release on different cadences: the gateway's single API accumulates client-specific conditionals, optional query parameters, and version branches, and every client's feature work queues behind the one team that owns that shared surface. Splitting into per-client BFFs - often still sitting behind a thin shared gateway for the cross-cutting concerns - removes that bottleneck and lets each frontend team iterate independently.
go deeper
Knows gateway and BFF are different things but may blur the distinction.
Can state gateway handles uniform/cross-cutting concerns while BFF handles per-client shaping.
Can describe layering both together and identify concrete signals for when to split or consolidate.
Can weigh organizational-scaling trade-offs and choose a topology for a given number of diverging clients and teams.
## What a gateway is for, and what a BFF is for An API gateway, in the generic sense, is an edge component whose job is largely client-agnostic: - terminate TLS, - authenticate the caller, - apply rate limits, - route the request to the right backend service, - maybe do request/response logging or basic protocol translation. Crucially, it usually exposes one API surface - the same routes, the same response shapes - to every consumer, because its purpose is centralizing infrastructure concerns that are the same regardless of who's calling. A BFF has essentially the opposite orientation: its API surface is intentionally **client-specific**, and its logic is about aggregation and view-shaping rather than infrastructure. Where a gateway asks "how do I route and secure this request uniformly," a BFF asks "what does this exact client need this exact response to look like." ## The two are layers, not rivals The two can and often do coexist as layered concerns rather than competing alternatives: a thin, shared gateway at the edge handles TLS termination, auth token validation, and rate limiting for all traffic, then routes requests onward to whichever BFF matches the calling client, and each BFF does the client-specific orchestration behind that. This avoids re-implementing cross-cutting infrastructure inside every BFF while still giving each frontend team ownership of its own response shape. Many real systems settle into exactly this topology: **gateway for infrastructure, BFFs for product logic**. ## Where the shared gateway breaks down The breakdown case for relying on a single shared gateway API (with no BFF layer) happens when clients' needs genuinely diverge and evolve on different timelines. Consider a company with a web app, an iOS app, and a third-party partner integration all hitting the same gateway API. | Consumer | What it now wants | |---|---| | **The web team** | wants a new nested field for an upcoming feature | | **The partner integration** | is contractually pinned to a stable schema and can't tolerate breaking changes | | **The iOS app** | wants a smaller payload because of a performance push | All three requirements land on the same shared endpoint, owned by one team. That team now has to reconcile mutually exclusive pressures - add the field without breaking the partner's stable contract, shrink the payload for iOS without shrinking it for web - typically by growing optional parameters, versioned response variants, or feature-flagged fields inside one increasingly complex API. Every client's roadmap becomes gated on that one team's prioritization and release process, which is precisely the bottleneck BFF ownership is designed to remove. ## The cost on the other side The cost on the other side is real, though: splitting a shared gateway API into several BFFs means more services to deploy, monitor, and secure-patch, and it requires clients or an org boundary that actually justifies the split - a single client with a single small backend has no divergent needs to serve and gains nothing from per-client BFFs, only the added hop and operational surface. The decision is not "BFF is always better than a gateway," it's recognizing which **cross-cutting** concerns genuinely belong at a shared edge layer (auth, rate limiting, TLS) versus which concerns are inherently **client-specific** (response shape, aggregation, view logic) and therefore belong closer to that client's owning team. ## Reading the signal in production A useful diagnostic in production is watching where change requests queue up. 1. If a single gateway team is consistently the bottleneck for unrelated frontend feature work - if a mobile team's sprint is blocked waiting on the gateway team to add an endpoint variant just for them - that's the concrete signal the shared-gateway model has broken down for that organization, and splitting client-specific aggregation into a BFF the mobile team owns directly removes the dependency. 2. Conversely, if several BFFs have converged to near-identical logic because the clients they serve no longer actually differ, that's the signal running the other way: the split isn't earning its operational cost anymore, and consolidating back toward a shared API (behind a shared gateway) removes duplicate deployments and code to keep in sync for no remaining benefit.
- Can a system use both a shared API gateway and per-client BFFs at the same time? What would each layer be responsible for?Yes - a common topology is an edge gateway (TLS termination, auth, rate limiting, routing) in front of several BFFs, each doing client-specific aggregation and shaping behind that gateway. The gateway stays a thin, client-agnostic infrastructure layer; the BFFs own product and view logic. This avoids duplicating cross-cutting concerns in every BFF while still giving each client team autonomy over its own API shape.
- What's a sign a team should merge several BFFs back into a single shared API instead of keeping them separate?If the BFFs have converged to near-identical response shapes and orchestration logic because the clients' actual needs are no longer meaningfully different, maintaining separate BFFs just adds duplicate deployments and code that has to be kept in sync for no real benefit - consolidating back to one shared API removes that overhead without losing anything clients actually needed.
A shared gateway is like one general receptionist trying to personally handle every visitor's unique request; a BFF setup is like each department having its own front desk tailored to its own visitors, while building security - the actual gateway - still checks everyone in at the main entrance.
saying these in an interview costs you the question
- conflates BFF and API gateway as literally the same thing
- thinks a gateway can't also route traffic onward to per-client BFFs
- doesn't distinguish cross-cutting infrastructure concerns from client-specific shaping concerns
- claims BFFs eliminate the need for any edge/gateway layer in every architecture
- can't name a concrete trigger for when a shared gateway API starts breaking down