Backend for Frontend (BFF)
Practice this topic in a realistic system design interview
An API gateway gives clients a controlled entry point. A Backend for Frontend goes one step further: it gives each type of client an API that fits how that client works.
A web app, mobile app, partner integration, and admin console may all use the same product data. But they often need different response shapes, caching rules, speed targets, permissions, and release schedules.
The Backend for Frontend (BFF) pattern creates a small backend for one client family. It receives client requests, calls backend services, combines the results, and returns a response that fits that client.
The goal is to keep client-specific behavior close to the client without stuffing it into core services or turning one shared gateway into a maze of client-specific branches.
This chapter covers how the backend-for-frontend pattern works and when a per-client backend is worth it.
1. The Problem: One API Shape Does Not Fit Every Client
Consider a product detail page used by three clients.
| Client | Needs |
|---|---|
| Web app | Full description, large images, reviews, related products, SEO metadata |
| Mobile app | Compact description, small images, rating summary, stock status |
| Partner API | Product ID, SKU, price, availability, bulk sync metadata |
Those clients are asking about the same product, but they do not need the same response.
Different Ways of Using the API
Each client type talks to the backend in its own way. A partner may run a scheduled sync job. A mobile app may make one call when a screen opens. A web app may fetch data while rendering a page. The diagram puts those flows side by side.
The mobile app cares about small responses and unreliable networks. The web app may care about server rendering, SEO metadata, and rich interactions. The partner API may prefer stable bulk exports instead of UI-friendly responses.
Different Release Cycles
Clients also ship on very different timelines. That limits how fast a shared API can change. The table shows the kind of release constraint each client brings.
| Client | Typical Release Constraint |
|---|---|
| Web app | Can deploy many times per day |
| iOS app | App Store review and slow client upgrade curve |
| Android app | Often faster than iOS, but still tied to app versions |
| Partner API | Breaking changes may require months of notice |
| Admin console | Operational workflows may need fast iteration and richer permissions |
A shared API has to protect the slowest-moving client. BFFs let each client-facing API change at the pace of that client.
Shared Gateway Drift
When every client-specific detail goes into one gateway, the gateway stops being a clean entry point.
Changes for one client start creating risk for every other client. Ownership also gets blurry: the platform team owns the gateway, but product teams keep adding product-specific behavior to it.