Fat vs. Skinny BFF: Understanding Backend‑for‑Frontend Patterns in Microservice Architecture

Microservice architecture often suffers from vague terminology and a lack of consensus; one such concept is BFF (Backend for Frontend), which serves as a unified entry point for front‑end integration.

The author defines BFF as the “application service” from the Chinese Communications Standard, and lists various synonymous names such as orchestration layer, service gateway, portal API, and experience/user API.

Fat BFF – a BFF with many responsibilities including authentication, rate‑limiting, circuit‑breaking, protocol integration (e.g., MQTT, WebSocket), orchestration of domain services, providing a single API set for different client types, and acting like the application layer in DDD. Its benefits are customized APIs per client, atomic domain services, easier client adaptation, fine‑grained auth, and unified API documentation, while its drawbacks are reduced end‑to‑end delivery, duplicated implementation, and maintenance complexity.

Skinny BFF – essentially a choreography pattern that mainly performs authentication and transparent request forwarding, with optional rate‑limiting and circuit‑breaking. Its advantages are better end‑to‑end delivery, higher development efficiency, and reduced integration steps; its disadvantages include lack of orchestration, tighter coupling between services, limited scalability, and over‑burdened domain services.

The article compares two design patterns: one using multiple dedicated BFFs for diverse entry points (high cost, suitable for multi‑channel systems) and another where the front‑end calls backend services directly (low cost, suitable for homogeneous clients).

Choosing between fat and skinny BFF depends on business scenarios: e‑commerce and internet finance often favor fat BFFs to handle many client types, whereas internal enterprise applications with uniform clients may prefer skinny BFFs to avoid redundant code, though Open API layers may still require orchestration.

In conclusion, both fat and skinny BFFs are outcomes of splitting monolithic systems based on context, and the optimal choice must tolerate the associated trade‑offs.

Reference materials:

Microservice structure – https://shaogefenhao.com/libs/webinar-notes/java-solution-webinar-3.html

Orchestration pattern – https://medium.com/gbtech/orchestration-pattern-3d8f5abc3be3

Why microservice orchestration matters – https://orkes.io/blog/why-is-microservice-orchestration-important-now

Orchestration vs. choreography – https://medium.com/geekculture/microservices-orchestration-vs-choreography-technology-5dbe612cf7e9