What problem does the Backend for Frontend (BFF) pattern solve, and how does it typically sit between a client app and the backend services?

## What a BFF actually is Concretely, a BFF is a dedicated backend service scoped to a single class of client - for example a `web-bff`, `ios-bff`, and `android-bff` sitting in front of the same set of domain microservices (`catalog-service`, `pricing-service`, `reviews-service`, and so on). When a client needs to render a screen, it makes one call to its own BFF rather than issuing several direct calls to those domain services and merging the results on-device. On the server side, the BFF then: - **fans those calls out** - often in parallel - and combines the responses; - **strips fields** the client doesn't need; - **renames or restructures fields** to match the client's view model; - returns a single, **purpose-built payload**. From the client's perspective, complexity that used to live in client code (orchestration, retries, merging heterogeneous response shapes) now lives in a service the client's own team controls. ## Why a single shared API is not enough The pattern exists because a single shared API trying to serve every client type accumulates awkward compromises. | Client | What it cares about | |---|---| | **Mobile** | A mobile client on a variable-quality network cares about round trips and payload size; it wants a small number of calls returning only what fits the screen. | | **Desktop web** | A desktop web client usually has more bandwidth and can afford a richer, more general response. | | **Partner** | A third-party partner integration needs a stable, generic contract that doesn't churn with every internal UI change. | A single endpoint trying to satisfy all three ends up growing conditional branches, optional query parameters, and rarely-used fields, and every client becomes coupled to the needs of every other client - a change requested by the mobile team can be blocked on negotiation with whoever owns the shared contract. Splitting into per-client BFFs removes that coupling: each client gets an API contract that only it needs to agree to, and the team that consumes it can usually also own it, which tracks **Conway's Law** - the system's API boundaries mirror the team boundaries. ## The trade-off The trade-off is real cost on the other side of that benefit. - **Another deployable.** Each BFF is another deployable service: another thing to build, test, deploy, monitor, and patch, even though its logic is often "just" orchestration and shaping. - **A network hop.** Introducing a BFF adds a network hop between client and domain services, which must be budgeted into the latency target. - **Business logic leak.** Because a BFF sits close to the client team rather than the domain team, there's a constant temptation to let real business logic (pricing rules, eligibility checks, validation) leak into it for convenience, which undermines the pattern if left unchecked - business logic belongs in the owning domain service, with the BFF limited to aggregation, orchestration, and presentation shaping. ## Failure modes in production In production, BFF-related failures usually show up in one of two ways. 1. **First**, if the BFF doesn't apply timeouts or circuit breakers to its downstream calls, one slow or failing dependency (say, the reviews service) can drag down every request that client makes, even for data that had nothing to do with reviews - the fix is per-dependency timeouts and graceful degradation, returning the page without the optional section rather than failing the whole response. 2. **Second**, if BFFs accumulate business logic independently, clients start disagreeing with each other - the classic symptom is an iOS app and a web app showing different prices or different eligibility results for the same account, because each BFF reimplemented the same rule slightly differently. ## Where the pattern comes from A widely cited real-world motivator for this pattern is Netflix's move away from one generic API meant to serve every device (TVs, game consoles, phones, browsers) toward device-tailored adapter layers, once the diversity of client devices made a single shared contract unworkable to evolve quickly. The BFF name itself was coined and popularized by Sam Newman, based on experience building systems this way at SoundCloud, and it has since become a standard pattern in mobile-heavy and multi-platform product organizations, especially once a company has more than one frontend team pulling a shared API in different directions.