When you build a shared API that serves a web app, an iOS app, and a smart TV, you eventually realize: every client is different, but your API pretends they're the same. The web wants rich nested data in one round trip. Mobile wants tiny payloads because the user is on a subway. The TV wants pre-formatted strings because rendering logic on a 5-year-old chipset is painful. The BFF pattern says: stop forcing one API to serve them all. Build a dedicated backend per frontend.

The architecture is simple: each client talks to its own BFF, which is a thin orchestration layer that calls the downstream microservices (users, orders, catalog, etc.) and shapes the response specifically for that client. The BFF owns the aggregation, the field selection, the version compatibility, and the client-specific business logic.

Real-world example: Netflix famously moved from a single REST API to per-device BFFs around 2012. Their TV BFF returns pre-resized image URLs and flattened metadata because TV remotes can't tolerate latency; their mobile BFF returns smaller payloads with paginated rows. SoundCloud, Spotify, and most large product companies do this now. A concrete pattern: your /home endpoint on web returns 50 fields per item; the same endpoint on mobile returns 8.

When BFF earns its keep:

• You have 3+ client types with meaningfully different needs (web, iOS, Android, TV, embedded).
• Clients are forcing ugly compromises into your core API — optional fields everywhere, ?include= query params nobody understands, version 7 of an endpoint.
• Mobile teams complain about chatty APIs requiring 8 calls to render one screen.

When it doesn't: If you have one web app and one mobile app that show roughly the same data, a BFF is overkill — you'll maintain two services instead of one. Wait until pain is concrete.

Rule of thumb — the 30% rule: if more than 30% of a client's API calls require client-specific transformation, shaping, or aggregation that doesn't belong in the core domain services, that client deserves its own BFF. Below 30%, push the variation into query parameters or GraphQL fragments instead.

Watch out for:

• Logic duplication. Three BFFs can independently reimplement the same "is this user a premium subscriber?" check. Extract shared logic into a library or a domain service.
• Ownership confusion. A BFF should be owned by the frontend team that consumes it — not the platform team. Otherwise it becomes another API gateway with a fancy name.
• Becoming a monolith. A BFF orchestrates; it doesn't own business rules. The moment a BFF holds the source of truth for an entity, you've leaked domain logic into the edge.