Understanding BFF (Backend For Frontends): Architecture, Types, Challenges, and Governance

In modern software development, the large scale of programs, teams, and data requires reuse of business capabilities by extracting domain services and providing generic functions to avoid duplicate code; microservice architecture has become inevitable, and with front‑back separation, BFF (Backend For Frontends) emerges as a crucial design component.

1. Why BFF: Connecting Past and Future

BFF stands for Backends For Frontends, offering a unified entry point that adapts backend capabilities to different front‑end scenarios, isolating varying API needs of multiple channels, allowing enterprises to build core domain capabilities in the backend, and enabling front‑ends to quickly satisfy UI requirements for better user experience.

BFF also facilitates migration or evolution of monolithic applications to microservices: a BFF layer can expose monolith services to the front‑end, after which the monolith can be split into domain services or middle‑platform services, with BFF or a front‑layer composing APIs, shielding front‑ends from backend changes.

2. Typical Inter‑Process Microservice Architecture

Using a food‑delivery system as an example, the system involves ordering users, merchant partners, and admin staff, accessed via mobile app, mini‑program, and web pages. Initially built as a large monolith with front‑back separation, business growth leads to many merchants and complex user demands, prompting a shift to microservices and the introduction of BFF.

Thin BFF

A thin BFF has minimal responsibilities, essentially acting as a gateway that forwards front‑end routes to domain services, while optionally handling generic functions such as authentication, rate‑limiting, circuit‑breaking, service degradation, and gray routing.

Thick BFF

A thick BFF extends the thin version by integrating additional protocols (e.g., MQ, WebSocket) and acting like the application layer in DDD, orchestrating multiple domain services and avoiding inter‑service dependencies.

Thin BFF suits low‑variance internal applications with fixed user groups and uniform interaction; thick BFF is appropriate for multi‑channel, complex business scenarios, and Open API can be viewed as a BFF with orchestration capabilities.

3. BFF Issues

Multiple front‑end channels often lead to duplicate code across different BFFs for the same functionality.

BFF may take on excessive business responsibilities, becoming an ESB‑like integration layer that aggregates many services to fulfill new requirements.

Having a single interface perform multiple write operations jeopardizes data consistency when multiple backend services need to be updated.

Performance can degrade because a BFF may need to call numerous backend services to assemble data for the front‑end, leading to high latency.

4. BFF Governance Directions

Principles:

BFF exists to improve front‑end user experience and orchestrate backend capabilities.

Business logic should reside in appropriate backend domain services, not in BFF.

Technical capabilities can be extracted into dedicated services when needed.

BFF should not act as a data‑integration layer; backend data changes must be synchronized directly between services.

Governance actions:

Prioritize solving backend service design issues first.

Analyze BFF interface responsibilities from a business perspective and keep them single‑purpose.

Sink business capabilities from BFF into backend domain services.

Extract reusable technical capabilities into shared libraries or dedicated backend services.

Limit the number of backend services a BFF depends on (preferably no more than five).

Avoid multiple write operations in a single BFF interface; enforce clear separation of concerns.

5. Conclusion

Whether thin or thick, BFF introduces both benefits and challenges; it should act as a bridge rather than a god‑like layer, focusing on front‑end experience optimization and the consolidation of domain and middle‑platform services, while maintaining clear separation between front‑end and back‑end for efficient collaboration.