intermediate8 min readUpdated 2026-06-08

BFF Pattern

Backend for Frontend (BFF) creates dedicated backend services for each frontend type (web, mobile, TV), tailoring API responses to each client's specific.

Quick answer: BFF Pattern

BFF Pattern is covered here as a practical system design concept. Backend for Frontend (BFF) creates dedicated backend services for each frontend type (web, mobile, TV), tailoring API responses to each client's specific. Use it to understand the Architecture Patterns idea, where it appears in production systems, and how to discuss it clearly in interviews.

Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.

Aspect	Details
What it is	A pattern where each frontend type (web, mobile, TV) gets its own dedicated backend service that tailors API responses to that client's needs
When to use	When different frontends need different data shapes, aggregation patterns, or performance characteristics from the same backend services
When NOT to use	When you have a single frontend type or when GraphQL's field selection eliminates the need for different response shapes
Real-world example	Netflix has separate BFFs for TV, mobile, and web — each optimized for the device's screen size, bandwidth, and interaction patterns
Interview tip	Explain that BFF is NOT just an API gateway — it contains client-specific business logic and data aggregation that the gateway should not own
Common mistake	Putting too much business logic in the BFF — it should aggregate and transform data from downstream services, not implement core domain logic
Key tradeoff	Client optimization vs service duplication — each BFF is tailored perfectly but you maintain multiple backend services with overlapping functionality

Why This Matters

A single generic API serving all clients leads to two problems: mobile apps receive unnecessary data (over-fetching wastes bandwidth and battery), and web apps need multiple API calls (under-fetching increases latency). BFFs solve this by putting a thin, client-aware layer between frontends and microservices. Each BFF team owns the full stack for their client type, reducing coordination overhead. This pattern is especially powerful for companies like Netflix and SoundCloud where the TV, mobile, and web experiences are fundamentally different.

System architecture diagram for BFF Pattern showing how services, databases, and caches connect — System architecture for BFF Pattern

The Building Blocks

Client-Specific API: Each BFF exposes an API tailored to its frontend. The mobile BFF returns minimal JSON; the web BFF returns richer payloads with precomputed values.
Data Aggregation: BFFs call multiple downstream microservices and combine results into a single response. One mobile screen might need data from user-service, order-service, and recommendation-service.
Response Transformation: BFFs transform backend data into frontend-ready shapes: formatting dates for the locale, computing display values, filtering irrelevant fields.
Ownership Model: Each frontend team owns their BFF, making changes without coordinating with other teams. The mobile team ships their BFF independently of the web team.
Protocol Translation: BFFs can translate between protocols: frontend speaks REST/GraphQL, BFF speaks gRPC to downstream services, getting the best of both worlds.

Under the Hood

In a typical setup, the web BFF receives a request for a product page. It calls three microservices in parallel: product-service (details, images), pricing-service (current price, discounts), and review-service (ratings, top reviews). It combines the results into a single JSON response with all the data the web page needs — no more, no less. The mobile BFF for the same product page calls the same services but returns only the product name, price, rating, and a single image URL — significantly smaller payload for mobile bandwidth.

Step-by-step diagram showing how BFF Pattern processes a request from start to finish — How BFF Pattern works step by step

The BFF runs as a separate service, typically deployed alongside its frontend. In Kubernetes, the web BFF and web frontend might share a namespace. The BFF handles authentication token validation, request caching, and error handling specific to its client. If the review-service is down, the web BFF might return the page without reviews (graceful degradation), while the mobile BFF might show a cached rating.

The anti-pattern to avoid is a "super BFF" that serves all clients — that is just an API gateway with extra steps. Each BFF should be independently deployable, owned by the frontend team that uses it, and contain only logic specific to that client's needs.

How Companies Actually Do This

Netflix operates separate BFFs for each device type — TV, iOS, Android, and web — each optimized for the device's capabilities. TV BFFs prebatch data for slow processors, mobile BFFs minimize payload size.

Comparison table for BFF Pattern contrasting approaches, tradeoffs, and when to use each — Comparing key aspects of BFF Pattern

SoundCloud pioneered the BFF pattern. Their mobile BFF aggregates data from 300+ microservices into mobile-optimized responses, reducing the number of API calls per screen from 10+ to 1.

Spotify uses BFFs to serve different clients with tailored responses. The desktop BFF returns richer playlist data with lyrics and social features, while the car BFF returns minimal voice-optimized data.

Common Pitfalls

Creating a 'God BFF' that serves all clients — this defeats the purpose and becomes a bottleneck. Each client type should have its own BFF
Duplicating business logic across BFFs — domain rules should live in downstream microservices. BFFs only aggregate, transform, and shape data
Not setting up shared libraries for common patterns — authentication, logging, and error handling code gets duplicated across BFFs without shared utilities

Data flow diagram for BFF Pattern showing how requests and responses move through the system — Data flow through BFF Pattern

Interview Questions Worth Practicing

When would you use a BFF pattern instead of GraphQL for solving the over-fetching problem?
How do you prevent business logic duplication across multiple BFF services?
What is the difference between a BFF and an API gateway?

The Tradeoffs

Client Optimization vs Maintenance Cost: Each client gets perfectly shaped responses, but you maintain N separate backend services that partially overlap in functionality.
Team Autonomy vs Consistency: Frontend teams own their BFF and move independently, but ensuring consistent behavior (auth, error handling) across BFFs requires shared standards.
BFF vs GraphQL: BFFs give full server-side control over responses; GraphQL lets clients self-serve. BFFs are better when response shapes are predictable; GraphQL when they are highly variable.

Component diagram for BFF Pattern showing each building block and its responsibility — Key components of BFF Pattern

How to Explain This in an Interview

Here is how I would explain BFF Pattern in a system design interview:

The BFF pattern creates a dedicated backend for each frontend type. Instead of one API serving web, mobile, and TV with different needs, each client gets a BFF that aggregates data from downstream microservices and shapes responses specifically for that client. A mobile BFF returns compact payloads; a web BFF returns richer data. This eliminates over-fetching for mobile and under-fetching for web. Each BFF is owned by its frontend team, so they ship independently. The key distinction from an API gateway: a BFF contains client-specific data aggregation logic, not just routing. The tradeoff is maintaining multiple services with some overlap. When asked about alternatives, I mention GraphQL as a single-API solution that lets clients select their fields.

Interview preparation checklist for BFF Pattern with key points to mention and mistakes to avoid — Interview tips for BFF Pattern

Original DosiBridge notes for BFF Pattern

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study BFF Pattern is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

Ownership Boundary: For BFF Pattern, decide the ownership boundary before choosing tools; otherwise the design looks clean but fails when bff changes.
Blast Radius: For BFF Pattern, decide the blast radius before choosing tools; otherwise the design looks clean but fails when pattern changes.
Deployment Path: For BFF Pattern, decide the deployment path before choosing tools; otherwise the design looks clean but fails when bff changes.
Runtime Coupling: For BFF Pattern, decide the runtime coupling before choosing tools; otherwise the design looks clean but fails when pattern changes.
Operational Handoff: For BFF Pattern, decide the operational handoff before choosing tools; otherwise the design looks clean but fails when bff changes.

Production review question

If a team adopts BFF Pattern, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track bff-pattern health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For BFF Pattern, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.