Backends for Frontends gives each user experience — web, mobile, partner integration — its own dedicated backend instead of routing every client through one general-purpose API. Each BFF aggregates downstream services and shapes responses for exactly one frontend, and the team building that frontend owns it.

The pattern trades deliberate duplication for independent evolution: each experience changes its contract at its own pace; the general-purpose API stops being where every client’s needs collide. SoundCloud, where the pattern was named, ran dozens of BFFs.

Backends for Frontends: each frontend calls its own BFF, owned by the same team; every BFF aggregates the shared, general-purpose downstream services and tailors the payload to its one experience.

How It Works

  • One BFF per user experience, not per platform vendor; experiences with near-identical needs share one.
  • The frontend team owns its BFF end to end: contract, aggregation logic, payload shape, release cadence.
  • The BFF fans out to downstream services and combines their responses into one payload — typically one call per screen.
  • Business rules stay downstream; the BFF holds only experience-specific aggregation, mapping, and edge concerns.

Failure Modes

  • The BFF accretes business logic and becomes a thin monolith per client; domain rules now live in several client-specific copies that disagree.
  • BFFs multiply unchecked — one per device model or sub-team — leaving dozens of near-identical services nobody consolidates.
  • Edge concerns reimplemented per BFF drift: one client receives a security fix while the others keep the hole.
  • A BFF fans out synchronously to many slow services; the aggregation hop becomes the dominant latency and availability bottleneck.

Verification

  • Network traces show one BFF round trip per screen or view at the 95th percentile.
  • Deployment logs show BFF releases riding the frontend’s cadence, with no coordinated downstream releases.
  • A change-coupling report shows business-rule changes landing in downstream services only; recurring BFF edits for policy changes flag logic leakage.
  • An API gateway is the single-front-door alternative; thin per-client gateway configurations blur into BFFs.
  • GraphQL on one shared endpoint lets clients shape responses themselves — an alternative when payload flexibility, not team ownership, is the goal.
  • Micro frontends extend the same per-experience ownership into the UI.

References