The Architecture of the BFF Pattern

A Backend for Frontend (BFF) is an edge service that owns the request and response shape for exactly one kind of client: it accepts a single call, fans out to the underlying microservices inside the datacenter, aggregates and trims their responses, and hands back precisely the payload that one screen renders — pushing orchestration and over/under-fetching off the network-constrained client and onto a server the frontend team controls.

That one sentence carries the whole architecture. The shape is three tiers, but the load-bearing idea is the middle tier's ownership boundary, not the box count:

• Clients — mobile app, web SPA, smart-TV app, partner API. Each has radically different screen sizes, latency budgets, and data needs.
• One BFF per client experience — a mobile BFF, a web BFF, and so on. Each is tuned to one client's contract and is free to differ wildly from its siblings.
• Shared microservices — user, order, recommendation, loyalty. These stay generic; they answer to every BFF and know nothing about any specific screen.

Where the BFF boundary sits — vs a shared gateway

The single most common confusion is "isn't a BFF just an API gateway?" No — they answer different questions and, in mature systems, they compose (gateway in front, BFFs behind it, as in the diagram).

The dividing rule: if a responsibility is identical for every client (auth, TLS, quota), it belongs in the gateway; if it exists because this client renders data differently, it belongs in that client's BFF. Aggregating four services into one home-screen payload is client-specific, so it is BFF work, never gateway work.

The team-topology angle (Conway's law made deliberate): Sam Newman's rule of thumb is "one experience, one BFF" — and critically, the BFF is owned by the same team that ships the client. That is what makes the pattern pay off: the mobile team can reshape its payload the same day it changes a screen, with no cross-team ticket to a central backend team. If a backend team ends up owning all the BFFs, you have quietly rebuilt a shared gateway and thrown away the whole benefit. Also note: it is one BFF per experience, not per microservice — a mobile BFF still talks to many services.

A traced example: the mobile home screen

The home screen needs four things: the user's name, their latest order's status, three product recommendations, and their loyalty-point balance. Those live in four separate microservices. Watch what changes when a BFF absorbs the orchestration. Assume mobile round-trip time (RTT) over cellular is ~120 ms; inside the datacenter, service RTT is ~10 ms.

Without a BFF — the client orchestrates

Even with 4 parallel connections the client is bottlenecked on cellular RTT and connection limits, and it downloads ~40 KB to display maybe 2 KB of it. The client also contains the join logic ("stitch order into profile, keep the top 3 recs"), duplicated in Swift and Kotlin, re-shipped through the app stores on every change.

With a BFF — the datacenter orchestrates

Result: one cellular round trip instead of four, ~6 KB instead of ~40 KB, and the join logic lives in one server-side place the mobile team owns. Meanwhile the web BFF, hitting the same services, returns the full recommendation list and richer order history — because a laptop on broadband can use it.

Pitfalls a working engineer hits

• Fan-out has no failure isolation. A BFF that awaits all four services returns nothing if one is slow — you have coupled the home screen's availability to the loyalty service's worst day. Wrap each downstream call in a per-call timeout and circuit breaker, and return a partial response (render the screen, hide the loyalty widget) instead of a 500.
• Logic duplication across BFFs → drift. Auth token handling, retry policy, and tracing get copy-pasted into every BFF and slowly diverge. Extract them into a shared library — but resist the temptation to merge the BFFs themselves into one "mega-BFF," which recreates the lowest-common-denominator problem you were escaping.
• The BFF becomes a distributed monolith. Business rules (pricing, eligibility, inventory) creep into the BFF because it's convenient. Now that logic is invisible to other clients and duplicated. Keep domain logic in the microservices; the BFF only aggregates and shapes.
• BFF proliferation. One-per-device (iOS BFF, Android BFF, iPad BFF…) explodes headcount and ops. Group by experience: iOS and Android usually share one "mobile" BFF because their needs are near-identical.
• N+1 fan-out inside the BFF. Fetching 20 recommendations then looping to call user-service once per author turns one screen into 21 in-DC calls. Batch (a single GET /users?ids=…) or the in-DC latency you saved reappears.

When to use it — and when NOT to

Concrete signals that point to a BFF: you have multiple heterogeneous clients (mobile vs web vs TV vs partner API) whose data needs genuinely diverge; some clients are network- or CPU-constrained; different teams own different frontends and are blocked waiting on a central backend team; and you are drowning in client-side aggregation or over-fetching.

Trade-offs vs named alternatives:

• vs a plain shared API gateway + generic REST endpoints. The gateway is far less code — one service, no per-client servers. But it forces a lowest-common-denominator payload: every client gets the same shape and must aggregate and trim itself. You gain simplicity and lose the ability to tune per client. Cost of BFF over this: N extra deployable services to build, run, secure, and monitor.
• vs a single GraphQL endpoint. GraphQL lets each client declare the exact shape it wants against one schema — no N backend servers, and per-client tailoring without per-client code. But it moves the complexity into query planning, exposes you to resolver N+1 storms, makes HTTP caching hard, and needs a team to own the shared schema and guard against expensive queries. You trade N maintained backends for one shared schema with its own governance burden.

Choose THIS (BFF) when client needs diverge sharply and frontend teams need to own their own edge to move independently. Prefer a shared gateway when your clients are homogeneous — one payload genuinely suits all of them. Prefer GraphQL when you want client-driven shaping without standing up and staffing one backend per client, and you can invest in schema governance and resolver performance.

Takeaways

• A BFF is a per-client edge service that does composition and shaping in the datacenter so a constrained client makes one call and gets exactly what it renders.
• The boundary is crisp: cross-cutting/generic work → shared gateway; client-specific aggregation and trimming → BFF. They stack, not compete.
• The payoff is organizational as much as technical — "one experience, one BFF," owned by the frontend team, so clients evolve without cross-team blocking.
• Guard the fan-out: per-call timeouts, circuit breakers, partial responses, and batching — otherwise you've built a fragile distributed monolith.

Re-authored and deepened for this guide. Sources: Phil Calçado, "The Back-end for Front-end Pattern (BFF)" (2015), documenting SoundCloud's origin of the term; Sam Newman, "Backends For Frontends" (samnewman.io) and Building Microservices, 2nd ed. (O'Reilly, 2021), ch. on API composition; Daniel Jacobson et al. on Netflix's device-specific API adapters; Microsoft Azure Architecture Center, "Backends for Frontends pattern." Latency and payload figures are illustrative worked values, not measurements from a specific system.