Backend for Frontend (BFF)
A dedicated backend per client type, shaped to that client's needs.
IntermediateWebPlatform
Instead of one generic API serving every client, each client type (web, mobile) gets its own backend that aggregates and shapes calls to downstream services exactly as that client needs them.
When to use it
- Web and mobile clients need meaningfully different response shapes or aggregation
- A shared generic API has become a compromise that serves no client well
Trade-offs
- Duplicated aggregation logic across BFFs unless carefully factored into shared libraries
- One more service per client type to build, deploy and operate
Components used
Single-Page AppMobile AppManaged App Service
How it works
- Each client type — web, mobile, partner API — gets its own backend service instead of sharing one general-purpose API.
- Each BFF aggregates and reshapes downstream services into exactly the payload its client needs, owned by the team that owns that client.
- Mobile can receive a small trimmed response while web receives a richer one, without either compromising for the other.
Used in the wild
- Mobile clients on constrained networks needing fewer, smaller round trips.
- Separate web and mobile teams that would otherwise contend over one shared API's roadmap.
- Public partner APIs requiring a stable contract independent of internal refactoring.
Good to know
- It emerged at SoundCloud around 2013 while decomposing a monolith, and was written up by Phil Calçado and later Sam Newman.
- The obvious risk is duplicated logic across BFFs. The discipline is that a BFF is presentation logic only — business rules belong in the downstream services.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.