A platform has a backend-for-frontend per client, and they have diverged with duplicated logic. Is BFF still the right pattern?
Show the full answer Hide the answer
The diagnosis
The pattern is right and the layering is incomplete. Backends-for-frontends exist so each client team can shape responses for its own surface without coordinating — that benefit is real and worth keeping.
The duplication indicates that logic which is genuinely shared has been implemented in each BFF instead of underneath them.
The distinction that resolves it
Shaping belongs in the BFF; domain logic belongs beneath it.
- Belongs in the BFF: response shape, field selection, aggregation across services for one screen, client-specific formatting, and pagination style. These legitimately differ per client and should not be shared.
- Belongs underneath: business rules, authorisation decisions, validation, and calculations. If mobile and web compute a price differently, that is a defect rather than a difference.
If the same domain logic appears in several BFFs, it belongs in a service or a shared library beneath them — and the fact that it was duplicated indicates the underlying service's interface was not sufficient for what the clients needed.
What to check before consolidating
Is the duplication actually duplication? Two clients solving similar problems in similar ways may be correct — coupling them means a change for one client can break another, which is the coordination cost BFFs exist to remove.
Duplication is cheaper than the wrong abstraction here, because BFFs are meant to diverge.
The failure mode to watch
A BFF becoming a second business-logic layer, where the underlying services are thin data access and the real behaviour lives in three parallel implementations. At that point the architecture has three applications sharing a database, with all the consistency risks and none of the benefits.
The tell: a business rule change requires editing several BFFs.
The ownership question that decides most of this
Who owns each BFF? Owned by the client team, it stays a shaping layer because that team's incentive is their own surface. Owned by a backend team, it accumulates domain logic and becomes the shared bottleneck the pattern was meant to avoid.