Backend for Frontend (BFF) Pattern

The Backend for Frontend (BFF) pattern creates a separate backend service tailored to the specific needs of each frontend client (web, mobile, TV, partner API), rather than forcing all clients to share a single general-purpose API.

What It Really Means

Different clients have fundamentally different needs. A mobile app on a cellular network needs compact responses, minimal round trips, and offline-friendly data structures. A desktop web dashboard needs rich, detailed payloads with real-time updates. A smart TV app needs a completely different data shape optimized for large screens and remote control navigation. A partner API needs stable, versioned endpoints with comprehensive documentation.

When you force all these clients through a single API gateway, one of two things happens: the API becomes a lowest-common-denominator that serves no client well, or it becomes an over-featured monster with client-specific query parameters, conditional fields, and response transformations that are impossible to maintain.

The BFF pattern solves this by giving each client type its own dedicated backend. The mobile BFF aggregates data from downstream services into compact responses. The web BFF returns richer payloads with different field sets. Each BFF is owned by the frontend team that consumes it, so they can evolve the API at the pace their client needs without coordinating with other teams.

Sam Newman popularized the pattern in his work on microservices. The key insight is that the BFF is not a general-purpose service — it is an extension of the frontend, living at the boundary between the client and the core domain services.

How It Works in Practice

Architecture Overview

Real-World Example: SoundCloud

SoundCloud adopted the BFF pattern to serve their web player, mobile apps, and third-party developer API. Each had different requirements:

• Web BFF: Returns full track metadata, waveform data, social interactions, and real-time comment streams. Optimized for the rich web player experience.
• Mobile BFF: Returns compact track data, pre-computed playlist sequences for offline mode, and image URLs at device-appropriate resolutions. Minimizes payload size and round trips.
• Public API BFF: Returns stable, versioned responses following the public API contract. Changes go through a deprecation process.

When the mobile team needed to add offline playlist syncing, they modified the Mobile BFF to return pre-computed sync deltas. No coordination with the web team or the core services team was needed.

What a BFF Does

Response aggregation: The mobile BFF calls the User Service, Order Service, and Recommendation Service, then merges the results into a single response optimized for the home screen.

Response shaping: The web BFF returns {user: {name, avatar, bio, stats, recentActivity}}. The mobile BFF returns {user: {name, avatarSmall}}. Same downstream data, different shapes.

Protocol translation: Core services use gRPC internally. The web BFF exposes REST endpoints. The mobile BFF might expose GraphQL for flexible querying.

Client-specific logic: The TV BFF applies different pagination (larger page sizes for TV grids), different image sizes, and different sorting optimized for TV UX.

Implementation

Trade-offs

When to Use the BFF Pattern

• Multiple client types with significantly different API needs (mobile, web, TV, partners)
• Frontend teams want autonomy to evolve their APIs without cross-team coordination
• Different clients need different aggregation, filtering, and shaping of the same data
• You want to optimize API responses for specific client constraints (bandwidth, screen size)

When NOT to Use

• You have only one client type — a single API gateway is sufficient
• All clients need essentially the same data in the same format
• Your team is small and does not have the capacity to maintain multiple BFF services
• The overhead of additional services outweighs the benefit of client-specific optimization

Advantages

• Each frontend team owns its own API — faster iteration and deployment
• APIs are optimized for specific client needs — better performance and UX
• Changes to one client's API do not risk breaking other clients
• Client-specific concerns (auth flows, response formats, caching) are isolated

Disadvantages

• Code duplication across BFFs — shared logic needs careful extraction
• More services to deploy, monitor, and maintain
• Risk of BFFs growing into monoliths with business logic that should be in domain services
• Added latency from the extra hop between client and domain services

Common Misconceptions

• "One BFF per frontend developer" — The BFF is per client type (mobile, web, TV), not per developer or per page. A mobile BFF serves the entire mobile application, not individual screens.

• "BFF is just an API gateway" — An API gateway provides routing, auth, and rate limiting. A BFF contains client-specific aggregation logic, response shaping, and protocol translation. A BFF may sit behind an API gateway.

• "Business logic belongs in the BFF" — The BFF should contain presentation logic (aggregation, formatting, field selection) but not business rules (pricing, validation, authorization). Business logic stays in domain services.

• "GraphQL eliminates the need for BFFs" — GraphQL allows clients to request specific fields, which reduces the need for different response shapes. However, BFFs still add value for aggregation across services, client-specific caching, and protocol translation. GraphQL can be the interface exposed by a BFF.

• "BFFs must be written in the same language as the frontend" — While it is common (Node.js BFF for a JavaScript frontend), it is not required. The BFF should be written in whatever language the team is productive in.

How This Appears in Interviews

The BFF pattern comes up in system design and API design interviews:

• "Design an API layer for a platform with mobile, web, and partner clients" — Introduce the BFF pattern, explain why a single API does not serve all clients well, and describe how each BFF is tailored. See our system design interview guide.
• "How do you avoid code duplication across multiple BFFs?" — Discuss shared client libraries for downstream service communication, shared types/contracts, and extracting common logic into domain services.
• "Should the BFF team be the frontend team or a separate backend team?" — Discuss team topology and the advantages of frontend team ownership.
• Practice with our API design interview questions.

Related Concepts

• API Gateway Pattern — Routing and cross-cutting concerns that complement the BFF
• Microservices Architecture — The backend services that BFFs aggregate
• Service Mesh — Handles BFF-to-service communication
• Domain-Driven Design — Keeping business logic in domain services, not BFFs
• Compare: REST vs GraphQL — GraphQL as a BFF interface
• System Design Interview Guide — Comprehensive preparation
• Algoroq Pricing — Practice API design interview questions