When to Use BFF and Should It Replace API Gateway?

In modern backend architecture, you’ll often encounter the BFF (Backend for Frontend) pattern. It appears in systems that serve multiple client applications — web apps, mobile apps, smart devices, and sometimes even desktop clients.

But there are also systems with only one frontend. Think about internal tools like banking dashboards, HR systems, or logistics panels. These applications usually run inside a protected corporate network and serve a single interface.

In those cases, introducing a BFF can feel unnecessary.

A natural question appears:

If there’s only one client application, why introduce another component? Isn’t a BFF just another proxy that forwards requests and adds network latency?

The answer becomes clearer when you look at how modern applications actually consume data.

When a Single Frontend Becomes Complex

Even when you have just one frontend, things can get complicated quickly.

A single page may require data from several backend services:

• user information

• orders

• products

• recommendations

• analytics

Each service might have its own API format. Some responses may contain unnecessary fields. Others might require complex parameters.

If the frontend communicates with all these services directly, it ends up responsible for:

• orchestrating multiple requests

• transforming responses

• handling errors across services

• managing pagination and filtering

Now imagine the same system supporting multiple clients — for example web and mobile apps. Suddenly the problem multiplies.

This is exactly the type of situation where the BFF pattern becomes useful.

Where the BFF Pattern Came From

The BFF pattern became widely known after SoundCloud redesigned its architecture.

Originally, SoundCloud had a single API layer that served both web and mobile clients.

Over time, problems appeared.

Mobile applications needed smaller responses to reduce network usage and save battery life. Web applications, on the other hand, needed richer data.

At the same time, backend teams became a bottleneck. Every change to the API required coordination with the same backend service.

SoundCloud solved this by splitting the API into separate BFF services, each designed specifically for a particular client.

Each BFF became responsible for its own interface.

This allowed teams to move faster and adapt APIs to the needs of each platform.

If you want to dive deeper into the original idea, Sam Newman wrote an excellent explanation of the pattern:

https://samnewman.io/patterns/architectural/bff/

Why BFF Works Well

The biggest advantage of BFF is client-specific APIs.

Instead of forcing every client to use the same backend contract, each client receives an API tailored to its needs.

For example:

• a mobile BFF can return smaller payloads

• a web BFF can include additional data

• an internal admin BFF can expose operational information

Another benefit is architectural evolution.

Extracting BFF services often helps break apart a monolithic backend using the Strangler Pattern, gradually replacing large components with smaller services.

You can read about that approach here:

https://martinfowler.com/bliki/StranglerFigApplication.html

Of course, there is also a downside.

Every BFF service requires infrastructure, monitoring, and maintenance. The system becomes more distributed and slightly more expensive to operate.

BFF vs API Gateway

A very common question appears at this point:

If we already have an API Gateway, why do we need a BFF at all?

To answer that, we need to understand the difference between the two.

What an API Gateway Actually Does

An API Gateway is the entry point to your backend system.

Its responsibilities are mostly infrastructural.

Typical tasks include:

• routing requests to the correct microservice

• terminating SSL connections

• limiting request rates

• validating authentication tokens

• distributing traffic across service instances

The important detail is that the gateway usually does not understand business logic. It simply forwards traffic to the correct place.

Examples of popular API gateways include:

https://konghq.com/

https://aws.amazon.com/api-gateway/

https://nginx.org/

What a BFF Is Responsible For

A BFF sits closer to the client and deals with client-specific logic.

Its responsibilities often include:

• aggregating data from multiple microservices

• transforming responses into UI-friendly structures

• filtering unnecessary fields

• adapting pagination or sorting

• adding fields used only by a specific interface

For example, a mobile client might request 10 items per page, while a web interface might request 50 items.

Instead of forcing the client to handle these differences, the BFF handles them internally.

How API Gateway and BFF Work Together

In mature architectures, the two components often work together.

The request flow usually looks like this:

Client → API Gateway → BFF → Microservices

The API Gateway handles infrastructure concerns such as security and routing.

The BFF handles client-specific logic and data aggregation.

Each component focuses on its own responsibility.

Should You Combine BFF and API Gateway?

Sometimes teams try to simplify their architecture by combining both responsibilities into one service.

At first, this may seem convenient.

But over time the service starts handling too many concerns:

• routing

• authentication

• rate limiting

• response transformation

• data aggregation

• pagination

• caching

The component grows larger and harder to maintain.

This is especially problematic in systems that continue to evolve.

When Combining Them Can Be Acceptable

There are situations where combining these roles may still be reasonable.

For example:

• a small internal application

• a single client interface

• a simple backend service

• minimal data transformation

• low system load

In such cases, introducing both an API Gateway and BFF might be unnecessary complexity.

But once the system grows — especially in microservice environments — separating responsibilities usually pays off.

When You Probably Need a BFF

A BFF becomes useful when:

• multiple clients require different data formats

• backend services return raw or legacy data

• pages need data aggregated from several services

• frontend teams need independent development cycles

• minimizing client requests is important for performance

When You Probably Don’t Need One

A BFF might be unnecessary when:

• the system is very simple

• there is only one backend service

• backend responses already match UI needs

• one team manages both frontend and backend

In those cases, adding a BFF layer may only introduce unnecessary complexity.

Who Should Own the BFF?

Another interesting question is organizational.

Should the BFF belong to the frontend team or the backend team?

There’s no universal answer.

In SoundCloud’s case, BFF services were maintained by frontend teams because they understood the client requirements best.

Conceptually, however, the BFF still operates on the backend side because it communicates with backend services.

In practice, many companies allow frontend teams to maintain BFF services while running them as backend components.

The correct decision depends heavily on your team structure.

Final Thoughts

The Backend for Frontend pattern is a powerful architectural tool, but it isn’t always necessary.

Use it when your system serves multiple clients, aggregates data from several services, or needs client-specific API contracts.

Avoid it when the system is small and simple.

And while combining BFF and API Gateway might work in early stages, separating responsibilities usually leads to cleaner and more scalable architectures in the long run.