Backend for Frontend (BFF)
A dedicated backend service tailored for a specific frontend (mobile, web, TV). Each frontend gets an API shaped to its exact needs instead of sharing one generic API.
What is Backend for Frontend (BFF)?
In short
A Backend for Frontend (BFF) is a separate API layer built and owned for one specific client type, such as iOS, Android, or web, that talks to the downstream microservices and returns exactly the data and shape that one client needs. Instead of every frontend sharing a single general purpose API, each frontend gets its own backend tuned to its screen sizes, network constraints, and data requirements.
What it actually is
A BFF sits between one frontend and your backend services. The web app calls a web BFF, the iOS app calls a mobile BFF, the smart TV app calls a TV BFF. Each BFF is a thin server that knows the quirks of its one client and nothing else.
The pattern was popularized by SoundCloud around 2015. They had moved from a single Rails monolith to microservices and found that one shared public API could not serve a desktop browser and a phone equally well. The phone needed less data, fewer round trips, and different fields. So they gave each client its own backend.
The key idea is ownership. The team that builds the iOS app also owns the iOS BFF. When the app needs a new field on the home screen, the same team changes the BFF and ships both together, without filing a ticket against a shared API team and waiting in a queue.
How it works under the hood
A BFF is usually an aggregation and translation layer, not a place for business logic. A single screen on a mobile app might need user profile, recent orders, and recommendations. Without a BFF the app makes three separate network calls and stitches the responses together on the device, which is slow on a cellular connection.
With a BFF, the app makes one call. The BFF fans out to the profile service, order service, and recommendation service in parallel, trims each response down to the handful of fields the screen shows, merges them into one payload, and returns it. The phone gets one small response instead of three large ones.
BFFs also handle client specific concerns: a different auth token format, response shaping so the TV gets large image URLs while the phone gets thumbnails, protocol translation, and per client rate limits. The downstream services stay generic and stable, and all client coupling lives in the BFF where it can change fast.
When to use it and the trade-offs
Reach for a BFF when you have two or more meaningfully different clients hitting the same microservices and a single shared API keeps getting pulled in conflicting directions. If you only have one web frontend, a plain API gateway is simpler and a BFF is premature.
The cost is duplication and more moving parts. Three clients means three BFFs to build, deploy, monitor, and secure. Logic that should be shared, like authentication or pagination helpers, can drift across them if you are not disciplined about extracting common libraries.
The other risk is scope creep. A BFF should aggregate and reshape, not own core business rules. If discounts or inventory logic leak into the BFF, you have rebuilt a monolith with extra steps. Keep that logic in the domain services and let each BFF stay a translation layer.
A concrete example
Picture a food delivery app. The home screen on the phone shows nearby restaurants with a small photo, an estimated delivery time, and a rating. The same company runs a web ordering site that shows full menus and a courier facing app that shows pickup addresses and turn by turn routes.
All three read from the same restaurant service, order service, and routing service. But their needs differ wildly. The phone BFF asks the restaurant service for nearby places, requests thumbnail image URLs, and drops the full menu to save bandwidth. The courier BFF ignores photos and ratings entirely and pulls addresses and route legs instead.
Each BFF returns a payload that maps one to one onto a screen, so the client code is mostly rendering with little client side stitching. When the courier team adds a new field for delivery instructions, they change the courier BFF and the courier app together and never touch the phone or web path.
Where it is used in production
SoundCloud
Coined and popularized the pattern after splitting their monolith, giving the mobile apps and web each a dedicated backend.
Netflix
Pioneered client specific edge APIs so each device type, from TVs to phones to game consoles, gets a tailored response.
Spotify
Uses client specific backend services so the desktop, mobile, and web players each receive payloads shaped for their UI.
Amazon Web Services
AWS documents and recommends the BFF pattern, often implemented with API Gateway and Lambda, one BFF stack per client.
Frequently asked questions
- How is a BFF different from an API gateway?
- An API gateway is one shared entry point that handles routing, auth, and rate limiting for all clients. A BFF is one backend per client type that also aggregates and reshapes data for that specific frontend. You often run both: the gateway in front, and a BFF per client behind it. The gateway is generic, the BFF is opinionated about one client.
- Who should own a BFF?
- The frontend team that consumes it. The whole point is that the team building the iOS app also owns the iOS BFF, so a new screen requirement is one team changing two things that ship together, with no cross team ticket and no waiting on a shared API team.
- Does each BFF need its own database?
- No. A BFF should be stateless and own no data. It calls the existing domain services for everything and just aggregates and reshapes their responses. If a BFF starts needing its own persistent store, that is usually a sign business logic has leaked into a layer that should stay thin.
- Will GraphQL replace the BFF pattern?
- Sometimes. A GraphQL gateway lets each client request exactly the fields it wants, which removes one reason for a BFF. But BFFs still help with client specific auth, protocol translation, heavy aggregation, and per client release cadence. Many teams run GraphQL inside a BFF rather than instead of one.
- How many BFFs should I have?
- Roughly one per distinct client experience, not one per microservice. Phone, web, and TV that differ a lot justify three BFFs. Two web apps that are nearly identical can share one. If you find yourself building a BFF per backend service, you have misunderstood the pattern.
Learn Backend for Frontend (BFF) hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Backend for Frontend (BFF) as part of a larger topic.
See also
Related glossary terms you might want to look up next.
API Gateway
A single entry point for all client requests that routes them to the appropriate microservice. Handles auth, rate limiting, and request transformation.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
GraphQL
A query language for APIs where the client specifies exactly what data it needs. No over-fetching, no under-fetching. One endpoint to rule them all.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.