Architecture
A Backend-for-Frontend architecture diagram with separate BFF layers for web and mobile clients, each optimizing API responses for their specific platform while sharing common backend microservices. This template shows how to avoid one-size-fits-all APIs by tailoring data aggregation and payload optimization per client type. Recommended for teams serving multiple frontend platforms from a shared microservices backend.
Full FlowZap Code
WebApp { # Web Application
n1: circle label:"Browser Request"
n2: rectangle label:"Web BFF"
n3: rectangle label:"Render HTML Response"
n4: circle label:"Display Page"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Services.n9.handle(top) [label="Fetch Data"]
n3.handle(right) -> n4.handle(left)
}
MobileApp { # Mobile Application
n5: circle label:"Mobile API Call"
n6: rectangle label:"Mobile BFF"
n7: rectangle label:"Optimized Payload"
n8: circle label:"Render Native UI"
n5.handle(right) -> n6.handle(left)
n6.handle(bottom) -> Services.n9.handle(top) [label="Fetch Data"]
n7.handle(right) -> n8.handle(left)
}
Services { # Shared Microservices
n9: rectangle label:"User Profile Service"
n10: rectangle label:"Content Service"
n11: rectangle label:"Notification Service"
n12: rectangle label:"Analytics Service"
n9.handle(right) -> n10.handle(left) [label="User Context"]
n10.handle(top) -> WebApp.n3.handle(bottom) [label="Full Payload"]
n10.handle(top) -> MobileApp.n7.handle(bottom) [label="Compact Payload"]
n11.handle(top) -> MobileApp.n7.handle(bottom) [label="Push Token"]
n12.handle(top) -> WebApp.n2.handle(bottom) [label="Track"]
n12.handle(top) -> MobileApp.n6.handle(bottom) [label="Track"]
}
Why This Workflow?
A single API serving both web and mobile clients forces compromises: web clients receive unnecessary mobile-specific fields, and mobile clients download bloated payloads. The BFF pattern creates dedicated API layers for each client type, optimizing response payloads, aggregation logic, and caching strategies per platform.
How It Works
- Step 1: The Web BFF aggregates data from shared microservices and renders full HTML payloads.
- Step 2: The Mobile BFF returns compact JSON optimized for bandwidth-constrained mobile networks.
- Step 3: Both BFFs call the same shared backend microservices for data.
- Step 4: Each BFF handles platform-specific concerns like push notifications or SSR.
- Step 5: Analytics tracking is integrated at the BFF level for platform-specific metrics.
- Step 6: Shared microservices remain platform-agnostic and focused on business logic.
Alternatives
A single API with field selection (GraphQL) can reduce the need for BFFs. API versioning per client type is simpler but harder to maintain. This template helps teams decide when a dedicated BFF layer is worth the operational cost.
Key Facts
| Template Name | Microservices Backend-for-Frontend (BFF) Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
An event-driven choreography architecture diagram where microservices coordinate through events without a central orchestrator, with Order, Payment, Inventory, and Shipping services reacting to each other's domain events. This template models the decentralized coordination pattern where each service knows only its own responsibilities and publishes events for others to consume. Best for teams favoring autonomous services over centralized workflow control.
Architecture
A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.
Architecture
An API composition architecture diagram with a composer service that fans out parallel requests to multiple microservices, collects responses with timeout handling, and merges results into a single unified response with partial fallback support. This template models the API composition pattern used when a single client query requires data from multiple services, avoiding the need for direct service-to-service calls. Useful for teams building aggregation layers in microservices architectures.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.