Understanding the Relationship Between Service Mesh and API Gateway

Service Mesh and API Gateway are often asked about together; this piece consolidates existing material, adds personal insight, and clarifies their distinct roles.

Clear boundaries: Service Mesh provides internal service‑to‑service communication, while API Gateway exposes services externally as APIs.

Service Mesh: infrastructure for intra‑system traffic.

API Gateway: entry point for external clients.

From a functional perspective, the architecture can be visualized as atomic microservices at the bottom, optional composite services above them, and the mesh handling internal calls, while the gateway routes external requests to these services.

East‑west vs. north‑south traffic: East‑west denotes internal service calls; north‑south denotes traffic entering or leaving the system via the gateway. Whether the gateway’s internal calls count as east‑west or north‑south depends on whether the gateway is viewed as a whole or split into inbound/outbound components.

Two implementation philosophies:

Separate: treat the gateway and internal services as independent, with the gateway implementing its own communication mechanisms.

Compatible: treat the gateway as a regular internal client, reusing the mesh’s communication stack.

Products reflect these choices: Kong follows the separate approach, while Spring Cloud’s Zuul and Spring Cloud Gateway adopt the compatible model.

When the gateway acts as a client, it inherits many mesh capabilities (service discovery, load balancing, retries, circuit breaking, observability, security, etc.), leading to code‑level reuse.

Sidecar convergence: In the mesh era, the gateway can be deployed as a regular service with a 1:1 sidecar, moving the gateway’s functionality into the sidecar and simplifying the gateway’s responsibilities.

Further evolution merges the gateway and sidecar into a single component, reducing the “extra hop” overhead.

BFF (Backend‑For‑Frontend): Adding a BFF layer between the gateway and internal services further refines traffic handling. The BFF fully absorbs external traffic, allowing the gateway‑sidecar to focus on API management while the BFF’s own sidecar handles internal calls.

Combining the gateway, sidecar, and BFF can lead to a decentralized architecture where each BFF instance carries its own gateway capabilities.

Final summary: Service Mesh and API Gateway have clearly separated responsibilities, but practical implementations increasingly blend them through library reuse, sidecar integration, and unified gateway‑sidecar solutions, with BFF patterns pushing the convergence even further.