Your mobile app makes 7 API calls just to load the home screen.
Your web app needs 3. Your TV app needs 12. They’re all hitting the same monolith API gateway.
That’s the trap.
One generic API serving every client type sounds efficient. In practice, it becomes a deployment bottleneck. Every team waits in line for the same backend to ship their changes.
The Backend for Frontend (BFF) pattern fixes this.
Instead of one API gateway trying to serve web, mobile, and TV, you build a dedicated backend for each client.
Each BFF is a thin service that sits between its frontend and your downstream microservices. It aggregates exactly the data that specific client needs. Nothing more.
SoundCloud pioneered this around 2013 when their monolith couldn’t keep up. Phil Calçado and Nick Fisher built dedicated backends per client type so each team could ship independently.
Sam Newman later formalized the pattern with a core principle: “one backend per user experience.”
Netflix took it further. With 1000+ device types, a single API gateway was never going to work.
Each client team owns its BFF, pulling data from microservices and formatting it precisely for that device. The Android team maintains the backend their app talks to, including all orchestration logic.
THE IMPACT OF BFF
→ Mobile calls drop from 7 per screen to 1 aggregated response
→ Each frontend team deploys independently without waiting on a shared gateway release
→ Over-fetching disappears because the BFF returns exactly what its client needs
→ Frontend-specific logic stays in the BFF instead of bleeding into shared services
The tradeoff is real. Every BFF is another service to deploy and monitor. Code duplication across BFFs is a constant risk.
If you’re not careful, a BFF can bloat into a second monolith.
The rule of thumb: if you have one client type, you don’t need a BFF. If you have three client types with different data needs and separate teams — you probably can’t afford not to have one.
What’s your current API gateway setup? Do you use a single gateway for all clients, or have you split by client type?
#SystemDesign #BackendEngineering #Microservices #SoftwareArchitecture

Joud Awad

The Backend for Frontend (BFF) pattern solves the problem of a single API gateway serving multiple client types (web, mobile, TV) with different data needs. Instead of one generic API, each client gets a dedicated thin backend service that aggregates exactly the data that client requires. Pioneered by SoundCloud in 2013 and later formalized by Sam Newman, BFF enables frontend teams to deploy independently, reduces over-fetching, and keeps frontend-specific logic isolated. The tradeoff is additional services to maintain and risk of code duplication. The pattern is most valuable when you have three or more client types with distinct data needs and separate teams.

Backend For Frontend Pattern