A backend for frontend (BFF) is a service dedicated to one client — web, mobile or another channel — that aggregates downstream services and returns exactly what that client needs. It keeps client-specific concerns out of the domain services and reduces round trips over slow networks.
Before you start
You should understand API gateways, aggregation and service boundaries. This article covers the BFF pattern and its pitfalls.
Step-by-step walkthrough
Step 1: Give each client its own BFF
A mobile app needs smaller payloads and fewer calls than a web dashboard, so a shared API forces compromises. A BFF per client lets each one shape responses for its constraints without changing the domain services.
Step 2: Aggregate and orchestrate calls
The BFF calls several services, possibly in parallel, and composes the result. It owns the client’s orchestration, so the client makes one call instead of many, which matters most on high-latency mobile networks. Keep the aggregation stateless and cheap.
Step 3: Hold client concerns, not domain logic
The BFF is the right place for response shaping, per-client caching and authentication for that client. It is the wrong place for pricing, validation or other business rules, which belong in the domain services. Pushing domain logic into a BFF creates a distributed monolith.
Worked scenario
The BFF composes two services into one mobile-shaped response.
GET /mobile/home
-> parallel: user-service /profile, order-service /recent
-> compose: { name, recentOrders: [ {id, total} ] } (drop unused fields)Walk through the example
Two downstream calls run in parallel and the BFF returns a single small object shaped for the mobile screen, dropping fields the client does not use. The client makes one request, and the domain services keep their general-purpose APIs. This is the aggregation the client would otherwise do in several round trips.
Common mistake
Letting the BFF grow business logic until it is a god service that every client depends on, which recreates a monolith. Another is sharing one BFF across clients, which brings back the compromises it was meant to remove.
Verify the behavior
Measure client round trips with and without the BFF and confirm the reduction. Assert the BFF returns only the fields the client needs. Review that the BFF contains no domain rules, only orchestration and shaping.
Interview exercise
Why per-client BFFs rather than one shared API gateway aggregation?
Answer and reasoning
Because clients have different payload sizes, call patterns and release cadences, and a shared layer forces them to compromise or accumulate client-specific branches. A BFF per client isolates those differences, so one client’s needs do not constrain another, and each team can evolve its own BFF. The gateway still handles cross-cutting concerns like routing and auth.
Continue learning
Compare the edge layer in API gateway. Read the microservices.io BFF pattern and try the Microservices interview questions.