Backend for Frontend (BFF)

Overview

Overview The Backend for Frontend (BFF) pattern creates dedicated backend services tailored to the needs of specific frontend clients. Instead of one generic API serving web browsers, mobile apps, smart TVs, and IoT devices alike, each client type gets its own backend that returns exactly the data it needs in exactly the format it expects.

The pattern emerged from a common frustration: mobile developers need small, efficient payloads optimized for limited bandwidth, while web developers need richer data for complex UIs. A single generic API either over-fetches for mobile (wasting bandwidth) or under-fetches for web (requiring multiple round trips). BFF solves this by giving each client type its own purpose-built API.

SoundCloud, Netflix, and Spotify are well-known adopters. In interviews, the BFF pattern is often discussed alongside API Gateway (which handles routing and cross-cutting concerns) and GraphQL (which provides flexible client-driven queries). Understanding when to use each approach is a signal of design maturity.

Key concepts

• Client-specific API backends
• Over-fetching and under-fetching problems
• API aggregation and composition
• GraphQL as a BFF alternative
• BFF ownership model (frontend team owns BFF)
• Mobile vs web data requirements
• BFF vs API Gateway distinction

Interview questions

• What problems does the BFF pattern solve, and how does it work?
• How is a BFF different from an API Gateway?
• When should you use GraphQL instead of (or alongside) BFFs?
• How should BFF ownership and deployment work in a team structure?

More Microservices topics

• API Gateway Pattern
• Bulkhead Pattern
• Circuit Breaker Pattern
• Configuration Externalization
• CQRS
• Event-Driven Architecture
• Retry Pattern
• Saga Pattern
• Service Discovery
• Sidecar Pattern
• Strangler Fig Pattern