We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Backend for Frontend across a run of lessons, not one page. These 4 alone are about 86 minutes of step-by-step reading, every one with a quiz.
A dedicated backend for each frontend, tailor your API to each client's needs.
Aggregate data from multiple microservices into a single response at the API layer.
The localStorage and sessionStorage APIs, simple key-value storage in the browser with cross-tab communication.
Protect your clean domain model from the messy reality of legacy systems and third-party APIs.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Backend for Frontend (BFF)pay once,
yours for life
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 came out of SoundCloud and was popularized by Sam Newman's 2015 write-up of it. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "Backend for Frontend (BFF)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Backend for Frontend (BFF) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Backend for Frontend (BFF) in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
