Understanding API Gateways, BFF, and Service Mesh in Microservice Architecture

According to Gartner, a microservice is a narrowly scoped, tightly encapsulated, loosely coupled, independently deployable and scalable application component.

Compared with a monolithic deployment, microservices aim to decompose applications into many loosely coupled services, providing benefits such as independent deployment, upgrade, scaling, maintenance, autonomous cross‑functional teams, and technical flexibility.

In a microservice architecture each service exposes a fine‑grained API for different clients (Web, mobile, third‑party).

Client‑to‑Microservice Connection Challenges

Fine‑grained APIs may require many round‑trips from the client, which is problematic for poor network conditions.

Multiple communication protocols (gRPC, Thrift, REST, AMQP, etc.) make client adoption difficult.

Each service must implement common gateway functions such as authentication, authorization, and logging.

Changing services without breaking client connections is hard, especially when merging or splitting services.

API Gateway

An additional layer placed between client and servers acts as a reverse‑proxy, providing a single entry point that encapsulates underlying system APIs. It is similar to an API manager but should not be confused with API management itself.

API Gateway Functions

Routing

The gateway encapsulates backend systems and provides a single entry point for clients to communicate with the microservice system.

Integration

The gateway consolidates common edge functionalities so each microservice does not need to implement them individually. Typical features include:

Authentication and authorization

Service discovery integration

Response caching

Retry policies, circuit breakers, QoS

Rate limiting and throttling

Load balancing

Logging, tracing, correlation

Header, query‑string, and claims transformation

IP whitelisting

IAM

Centralized log management (transaction IDs, error logs, etc.)

Identity provision, verification and authorization

Backend‑for‑Frontend (BFF) Pattern

BFF is a variant of the API gateway that provides multiple client‑specific gateways instead of a single entry point, delivering tailored APIs for each client type and reducing waste from a one‑size‑fits‑all approach.

How Many BFFs Are Needed?

The basic idea is to develop a niche backend for each user experience. Phil Calçado recommends “one experience, one BFF”. When client requirements differ significantly across iOS, Android, and web, and release cadence is strict, a BFF is advantageous, though complex designs require more steps.

GraphQL and BFF

GraphQL is an API query language. While BFF and GraphQL share similar goals, they are not mutually exclusive; BFF concerns client autonomy, whereas GraphQL shapes the API surface.

Well‑Known API Gateways

Netflix – Zuul

Netflix serves over 1,000 device types and handles 50,000 requests per second at peak. Zuul 2 acts as the first entry point to Netflix’s cloud, providing routing, protection, and scalability for 125 million members.

AWS API Gateway

A fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs, with data stored on AWS cloud.

Kong Gateway

An open‑source, lightweight microservice API gateway offering low latency and high scalability; additional nodes enable horizontal scaling.

Other Gateways

Apigee API Gateway

MuleSoft

Tyk.io

Akana

SwaggerHub

Azure API Gateway

Express API Gateway

Karken D

Choosing the Right Gateway

Evaluation criteria include ease of use, open‑source vs proprietary, scalability, flexibility, security, feature roadmap, community support, management (monitoring, deployment), installation/configuration, hosted options, pricing, and documentation.

API Composition and Aggregation

Simple requests can be routed directly to a single service, but complex operations requiring data from multiple services need API composition/aggregation. Synchronous dependencies may require chain composition, and the composition layer should support ESB‑like features such as transformation, orchestration, resilience, and stability.

Root containers must include dispatchers (splitting tasks) and aggregators (collecting results) to coordinate microservice workflows.

API Gateway and Aggregation

Gateways with complex aggregation increase testing and deployment difficulty; it is recommended to keep aggregation and data transformation out of the gateway and implement domain‑specific logic within application code. Netflix Zuul 2 removed many business logics from the gateway.

Service Mesh vs API Gateway

Service Mesh provides a configurable network layer for inter‑process communication, similar to sidecar proxies, offering load balancing, service discovery, health checks, and security.

While both address similar problems, API gateways handle external (north‑south) traffic and are part of business solutions, whereas Service Mesh manages internal (east‑west) traffic between microservices.

Combining both can improve uptime and scalability, but they should be viewed as complementary tools rather than interchangeable products.

Implementation Considerations for API Gateways

Potential single point of failure or bottleneck.

Additional network hop and complexity can increase response latency.