API Gateway vs BFF vs Direct Service Access

Medium•

Gateway vs BFF Boundary Map

System Boundaries

API Gateway

Infrastructure edge

- Routing/auth/rate controls
- Not UI contract shaping

BFF

Frontend-oriented layer

- Aggregate + shape responses
- Client-specific orchestration

Direct access

No middle adaptation

- Simple topology
- Higher frontend coupling risk

Selection

Fit-for-context decision

- Product/client diversity
- Ownership + ops capacity

Core Lens

Choose boundaries by responsibility and team topology, not by naming convention.

Flow

Ingress→

Policy enforcement→

Orchestration→

Client contract delivery

These patterns are often discussed together, but they should not be treated as interchangeable. A good architecture uses each layer for a clear purpose. The gateway should remain focused on platform-level concerns. The BFF should improve frontend delivery speed and contract quality without becoming a replacement domain service. Direct service access should stay simple and intentional, not become accidental tight coupling. Strong frontend engineers know when each model improves developer experience and when it only adds extra hops and duplicated logic.

Quick Navigation: Why This Matters • Pattern Definitions • Typical Request Flow • Responsibility Split • Tradeoffs by Pattern • When BFF Is Especially Useful • When Direct Access Is Enough • Team Topology and Ownership

Quick Decision Guide

Senior-Level Decision Guide:

- API Gateway is the platform entry layer for cross-cutting concerns like routing, auth enforcement, quotas, rate limiting, and traffic policy. - BFF is a client-focused application layer that shapes payloads, orchestrates backend calls, and optimizes contracts for a specific frontend surface. - Direct service access can be a valid choice when the system is simple, the service contracts are stable, and frontend-specific shaping is minimal. - Do not pick these patterns by trend. Choose them based on number of clients, contract diversity, ownership boundaries, security constraints, and iteration speed needs. - The biggest mistake is letting every layer absorb partial business logic until responsibilities become blurred.

Why This Matters

This topic matters because frontend teams often feel the pain first when backend boundaries are unclear. Symptoms include:

•the frontend must fan out to multiple services and manually stitch data together

•mobile and web need different payload shapes but share one awkward generic API

•auth or permission logic leaks into the client

•small UI changes require coordinated releases across many backend services

•multiple layers each implement slightly different business rules

In interviews, a strong answer shows that you understand why these layers exist and how to keep them from becoming architectural clutter.

Pattern Definitions

API Gateway

An API Gateway is the common entry point into backend systems. It usually handles:

•routing requests to internal services

•authentication and coarse authorization enforcement

•rate limiting, quotas, throttling, and traffic policy

•request logging, tracing, and observability hooks

•protocol translation in some architectures

The gateway is primarily an infrastructure and platform boundary, not a frontend-specific view layer.

BFF (Backend for Frontend)

A BFF is a backend layer designed around the needs of a specific client or product surface. It usually handles:

•shaping payloads for a specific frontend

•aggregating multiple backend calls into one client-friendly response

•hiding backend topology from the frontend

•simplifying frontend release velocity by reducing orchestration in the browser

•applying client-specific caching or response tailoring

A BFF is an experience and contract optimization boundary, not a home for core domain rules.

Direct Service Access

Direct service access means the frontend calls backend services directly, with little or no intermediate client-specific backend layer. This can work well when:

•the product is simple

•the number of clients is small

•the service contracts are already close to what the frontend needs

•orchestration complexity is low

Direct access is not automatically bad. It becomes risky when complexity grows but boundaries do not evolve.

Typical Request Flow

Gateway Only

Client -> API Gateway -> Backend Services

This is common when platform policies matter, but client-specific shaping is still limited.

Gateway + BFF

Client -> API Gateway -> BFF -> Backend Services

This is common when the organization wants a shared entry layer plus a client-specific shaping layer.

Direct Service Access

Client -> Backend Service

This is simplest operationally, but it exposes the frontend more directly to backend contract changes.

A strong answer should explain not only the flow, but also why each hop exists.

Responsibility Split

A good architecture keeps each layer narrow and explicit.

What belongs in the API Gateway

•authentication enforcement and token validation

•traffic controls

•basic routing

•observability hooks

•coarse policy enforcement

What belongs in the BFF

•client-specific payload shaping

•orchestration across services for one screen or flow

•hiding backend fragmentation from the frontend

•reducing over-fetching and under-fetching for a specific client

•frontend-friendly error shaping

What belongs in domain services

•business invariants

•pricing logic

•inventory truth

•permission truth at the domain level

•workflow correctness

What should stay in the frontend

•local UI state

•interaction state

•rendering logic

•lightweight formatting and display-only derivations

If the BFF starts owning domain truth, the boundary becomes dangerous. If the frontend starts orchestrating too much, the client becomes fragile and hard to evolve.

Tradeoffs by Pattern

API Gateway

Strengths

•central policy enforcement

•standardized observability and traffic controls

•consistent entry path for many services

Weaknesses

•can become overloaded with logic that does not belong there

•often too generic to solve frontend-specific shaping needs

BFF

Strengths

•improves frontend iteration speed

•reduces frontend orchestration complexity

•shapes contracts around real UI needs

•especially useful when web and mobile differ significantly

Weaknesses

•adds another deployable layer

•can become a mini monolith if it absorbs too much logic

•may duplicate patterns if many BFFs are created carelessly

Direct Service Access

Strengths

•simplest topology

•fewer hops

•lower operational overhead in small systems

Weaknesses

•frontend becomes tightly coupled to backend service structure

•harder to evolve when multiple services are needed for one screen

•contract changes can break clients more directly

•security and token handling can get messier depending on architecture

When BFF Is Especially Useful

A BFF becomes very valuable when:

•one page needs data from multiple services

•the frontend currently performs expensive orchestration itself

•web and mobile need different response shapes

•backend services are owned by different teams and expose domain-first rather than UI-first contracts

•the product is moving fast and UI-specific contract changes are frequent

Example:

A dashboard page may need profile data, feature flags, notifications, recommendations, and usage summaries. Without a BFF, the client may issue many calls and own retry/orchestration complexity. With a BFF, the client can call one contract designed for that surface.

When Direct Access Is Enough

Direct service access can be the right choice when:

•a single service already exposes a clean contract for the UI

•the frontend surface is small and stable

•the team is small and values simplicity over extra layering

•there is little client-specific transformation needed

Example:

A simple settings page that reads and updates profile preferences from one service may not need a BFF. Adding a BFF there could add complexity without meaningful product benefit.

Team Topology and Ownership

Boundary decisions should reflect how teams actually work.

Small team or early product

A direct model or light gateway can be enough.

Multiple frontend clients

A BFF often helps when web, mobile, and partner clients need different payloads or release independently.

Platform-heavy organization

A gateway plus BFF layering is common when the platform team owns shared edge concerns and product teams own client-specific contracts.

The wrong architecture often comes from ignoring team boundaries. A technically elegant model can still fail if no team clearly owns the layer.

State Management and Frontend Impact

These backend boundary choices directly affect frontend state architecture.

With direct service access

The frontend may need to:

•orchestrate multiple calls

•merge responses

•coordinate retries and partial failures

•manage more client-side loading states

With a BFF

The frontend often becomes simpler because:

•one surface can fetch one shaped payload

•fewer partial states leak into the UI

•client caching becomes easier

•the UI code focuses more on rendering than service choreography

Important nuance

A BFF does not remove the need for good frontend state management. It only reduces unnecessary backend-topology awareness in the client.

Failure Modes

Common mistakes include:

1. Frontend recreates orchestration because BFF is too thin

This defeats the purpose of the BFF.

2. BFF becomes a hidden domain layer

This causes business logic duplication and long-term maintenance pain.

3. Gateway absorbs frontend-specific shaping

This makes the gateway harder to maintain and turns infrastructure into product logic.

4. Direct access survives too long as complexity grows

The frontend becomes tightly coupled to too many backend services.

5. Ownership is unclear

Teams do not know who should change contracts, fix bugs, or evolve payloads.

Selection Heuristics

Use these questions:

1. How many clients do we have?

2. Do they need different payload shapes?

3. Is the frontend currently orchestrating multiple services?

4. Are security and token handling simple enough for direct access?

5. Does the org have clear ownership for a BFF layer?

6. Would a BFF meaningfully improve frontend speed and reduce coupling?

A simple heuristic:

•choose direct access when complexity is low and stable

•choose gateway only when central platform policy matters but client shaping is limited

•choose gateway + BFF when client-specific shaping and orchestration matter enough to justify an explicit layer

Interview Rubric

A weak answer says:

•“Use a BFF because it is modern.”

A better answer says:

•“Use a BFF because the web app needs aggregated payloads from multiple services, the mobile app needs a different contract, and we want the frontend to stop owning service orchestration.”

A strong answer should include:

•explicit responsibility boundaries

•why one pattern fits the current product shape

•why alternatives were not chosen

•what failure mode the chosen design prevents

•how the design might evolve as the system or org grows

Responsibility Boundaries

A good rule of thumb:

•Gateway owns shared entry concerns.

•BFF owns client-facing contract shaping and orchestration.

•Domain services own business truth.

•Frontend owns rendering, interaction state, and user experience.

The more clearly you can say this in an interview, the stronger your answer sounds.

Topology and Team Fit

Do not choose architecture by fashion. Choose it by:

•product complexity

•client diversity

•ownership clarity

•operational maturity

•release speed needs

A simpler architecture with clean ownership is often better than a layered one with vague boundaries.

Interview Deep Dive

A staff-level answer usually includes both:

1. the best choice for the current system

2. the likely evolution path as product scope grows

Example:

•today: direct access may be fine because one frontend surface uses one stable service

•later: add a BFF when multiple clients emerge and the frontend starts stitching several services together

This kind of answer shows architectural judgment instead of pattern memorization.

Key Takeaways

1API Gateway, BFF, and direct service access solve different classes of problems.

2API Gateway is best for shared entry concerns, not frontend-specific payload shaping.

3BFF is best for client-specific contract shaping and orchestration, not core domain truth.

4Direct access is valid when complexity is low, stable, and close to the frontend’s needs.

5The right boundary depends on client diversity, security constraints, ownership, and iteration speed.

6A BFF should reduce frontend orchestration complexity, not duplicate domain logic.

7Boundary choice should reflect team topology as much as technical design.

8Strong interview answers explain responsibility boundaries, tradeoffs, and rejected alternatives.