Backend for Frontend Pattern: Mermaid Flowchart

Backend for Frontend Pattern flowchart diagram

About Source

The Backend for Frontend (BFF) pattern introduces a dedicated API layer for each type of client — web, mobile, and third-party — so that each client gets a tailored interface without bloating the underlying microservices with client-specific logic.

What the diagram shows

This flowchart illustrates three client types — Web App, Mobile App, and Third-Party API Consumer — each communicating with its own dedicated BFF service rather than directly with the shared backend microservices.

Each BFF: - Accepts the request from its specific client type - Aggregates data from multiple downstream microservices (User Service, Product Service, Order Service) in parallel or in sequence - Shapes the response to match the client's data requirements — the mobile BFF returns a compact payload optimized for bandwidth, while the web BFF returns richer data for a full-featured UI

The downstream microservices remain generic and client-agnostic. They expose simple, fine-grained APIs, and all client-specific aggregation logic lives in the BFF.

Why this matters

Without BFFs, a single generic API must satisfy the conflicting needs of every client type. Mobile apps on limited bandwidth need small payloads; web apps need rich data; third-party consumers need stable, versioned contracts. Trying to satisfy all three with one API leads to either over-fetching, under-fetching, or a bloated API surface.

BFFs solve this by giving each team ownership of their client's API contract. Changes to the web experience don't risk breaking the mobile app. The pattern pairs naturally with GraphQL Query Execution — some teams implement BFFs as GraphQL gateways. For the upstream routing layer, see API Gateway Request Flow.

Frequently asked questions

The Backend for Frontend pattern creates a dedicated API layer for each type of client — typically one BFF for web, one for mobile, and one for third-party consumers. Each BFF aggregates data from shared microservices and shapes the response to match its specific client's needs, rather than forcing a generic API to satisfy conflicting requirements from all clients simultaneously.

Each client communicates only with its own BFF. The BFF accepts the client's request, makes parallel or sequential calls to multiple downstream microservices (such as User Service, Product Service, and Order Service), and composes the results into a single response tailored to that client. The mobile BFF might return a compact payload optimized for bandwidth, while the web BFF returns richer data for a full-featured interface.

Use BFF when different client types have significantly different data requirements and you find a single API being pulled in conflicting directions — adding fields mobile doesn't need, or removing detail the web app requires. It is especially valuable in large organizations where separate teams own web and mobile products and need independent deployment cycles.

The most common mistake is creating a BFF that becomes a generic aggregation layer shared by all clients — defeating the purpose of the pattern. BFFs should be client-specific and owned by the team that builds that client. Another pitfall is embedding business logic in the BFF rather than keeping it in the downstream microservices; BFFs should aggregate and adapt, not own domain rules.

mermaid

flowchart LR
    WA([Web App]) --> WBFF[Web BFF]
    MA([Mobile App]) --> MBFF[Mobile BFF]
    TP([Third-Party Consumer]) --> ABFF[API BFF]

    WBFF --> US[User Service]
    WBFF --> PS[Product Service]
    WBFF --> OS[Order Service]

    MBFF --> US
    MBFF --> PS

    ABFF --> PS
    ABFF --> OS

    US --> DB1[(User DB)]
    PS --> DB2[(Product DB)]
    OS --> DB3[(Order DB)]

    WBFF --> WA
    MBFF --> MA
    ABFF --> TP