BFF and API Composition

Backend-for-Frontend (BFF) is a backend layer optimized for one client type. API composition gathers data from multiple services and turns it into one client response. This layer should provide client-oriented orchestration, not become a new domain owner.

Quick Decision

Situation	Approach	Watch out
Web and mobile responses differ	Separate BFFs	Do not duplicate domain rules
One screen needs 3+ services	Composition	Design partial failure and timeouts
Only routing/auth/rate limits are needed	API Gateway	Keep orchestration out of the gateway
The same aggregation serves many clients	Domain/query service	Do not turn the BFF into a shared platform

Production Checklist

• Problem: Which client experience or network cost does the BFF improve?
• Solution: Are downstream fan-out, timeout, auth propagation, cache, and response contract clear?
• Trade-off: Fewer round trips and better payloads come with another deployable service and ownership.
• Failure mode: Define partial response, stale data, one-dependency timeout, and client-specific fallback behavior.
• Measurement: Track fan-out count, aggregate p95, downstream contribution, payload size, and errors.
• Security/cost: Do not pass client tokens to unnecessary services; fan-out raises connection and compute cost.

Gateway vs BFF

A gateway applies shared network policies: TLS termination, routing, authentication, rate limiting, correlation IDs, and simple transformation. A BFF knows the client-specific response model and call orchestration.

Putting domain aggregation in the gateway creates centralized change and a single failure point. A BFF should also avoid copying domain rules; the downstream service remains the source of truth.

API Composition

Make these boundaries explicit:

1. Validate client auth and tenant context.
2. Start independent calls with bounded parallelism.
3. Apply a deadline, retry, and circuit policy per downstream.
4. Separate required and optional response parts.
5. Report partial failure, cache staleness, or fallback through explicit metadata.

If core order data is required but recommendations are optional, a recommendation timeout should not fail the order response. Returning 200 while hiding missing required data violates the contract.

Cache, Auth, and Ownership

Key BFF response caches by user, tenant, locale, and permission scope; never write personal data to a shared cache. Repeat downstream authorization; a header from the BFF is not proof of identity.

Each BFF needs an owner, deployment independence, an SLO, and a downstream dependency budget. Too many BFFs with shared transformation and duplicated auth code create another monolith.

When Not to Use One

Do not add a BFF just to proxy one downstream call, rename a field, or hide domain rules. First evaluate pagination, field selection, caching, and client SDK options in the existing API.