Service Mesh vs API Gateway: Roles, Overlaps, and Integration Strategies

The relationship between Service Mesh and API Gateway has been a frequent topic in the past two years, with many community articles and influencer analyses. This piece consolidates those resources, adds personal insights, and concludes with Ant Financial's pioneering practices that blend Service Mesh and API Gateway.

1. Clear Boundaries: Position and Responsibility

Service Mesh provides the underlying network infrastructure for internal microservice communication, while API Gateway exposes services externally as APIs. Diagrams illustrate the layered architecture: atomic microservices at the bottom, optional composite services above them, and the gateway at the system edge.

From a deployment perspective, Service Mesh lives inside the system, whereas API Gateway sits at the perimeter, handling both external exposure and internal service access.

Two traffic‑direction terms are introduced: east‑west (internal service‑to‑service calls) and north‑south (external requests entering the system).

2. Philosophical Question: Is Gateway‑to‑Internal Traffic East‑West or North‑South?

If the API Gateway is viewed as a whole, its internal calls appear north‑south because external traffic first reaches the gateway. If the gateway is split logically—ignoring its external façade—the internal calls resemble east‑west traffic, treating the gateway as a regular client.

Two implementation philosophies arise:

Separate: the gateway implements its own client‑side communication, independent of the mesh.

Compatible: the gateway reuses the mesh’s client‑side mechanisms.

Both approaches eventually provide the same set of capabilities (service discovery, load balancing, retries, circuit breaking, observability, security, etc.), leading many teams to reuse existing mesh libraries when building a gateway.

3. Sidecar: The Real Overlap

When Service Mesh became mainstream, some projects began embedding a sidecar alongside the API Gateway, effectively merging the gateway’s client functions with the mesh’s sidecar. This reduces duplication and allows the gateway to focus on API management.

Examples include Ant Financial’s SOFA Gateway built on MOSN, and open‑source projects Ambassador and Gloo built on Envoy.

Although adding a sidecar introduces an extra hop, the performance impact is often mitigated by consolidating gateway logic into the sidecar itself.

4. BFF: Taking the Fusion to the End

Backend‑For‑Frontend (BFF) adds a layer between the gateway and internal services, aggregating multiple services specifically for front‑end needs. Unlike generic composite services, BFF fully owns external traffic.

When the sidecar‑enabled gateway is merged with BFF, the request path may contain two sidecars: one attached to the BFF and another representing the gateway‑sidecar. Experiments show that collapsing these into a single sidecar simplifies the topology.

In this configuration the physical gateway disappears; each BFF instance carries its own sidecar, achieving a decentralized gateway architecture.

5. Summary

Overall, Service Mesh and API Gateway have historically clear, separate responsibilities, but recent trends show increasing convergence through library reuse, sidecar integration, and BFF‑driven decentralization. Ant Financial’s experiments illustrate how MOSN‑based sidecars can power both mesh and gateway functions, hinting at future cloud‑native networking patterns.

MOSN (Modular Open Smart Network) is a Go‑based, cloud‑native proxy developed by Ant Financial, supporting xDS APIs and usable as a Service Mesh data plane, load balancer, API gateway, or ingress controller.

For deeper reading, see the InfoQ article: https://www.infoq.cn/article/azCFGyTDGakZqaLEEDMN.