What is a service mesh and how does it differ from an API gateway?
Learn what a service mesh is, how it manages internal traffic with sidecars, and how it differs from an edge API gateway — with examples and interview tips.
Expected Interview Answer
A service mesh is a dedicated infrastructure layer that manages service-to-service (east-west) communication inside a cluster using sidecar proxies, while an API gateway sits at the edge and manages client-to-service (north-south) traffic entering the system.
A service mesh injects a proxy (like Envoy) next to every service, transparently handling retries, mutual TLS, traffic splitting, and telemetry without changing application code. An API gateway is a single centralized entry point that authenticates external callers, routes requests, aggregates responses, and enforces rate limits. They are complementary: the gateway governs who gets in, and the mesh governs how internal services talk to each other securely and observably.
- Zero-code retries, timeouts and circuit breaking
- Automatic mutual TLS between services
- Fine-grained traffic control for canary and blue-green releases
- Uniform observability across all services
- Separation of edge concerns from internal concerns
AI Mentor Explanation
Think of the on-field umpires versus the stadium gate security. The gate security checks tickets and IDs before anyone enters the ground — that is the API gateway controlling who comes in. The umpires standing among the players manage every delivery, no-ball and appeal between the two teams in real time — that is the service mesh governing how the players interact once inside.
Step-by-Step Explanation
Step 1
Identify traffic direction
Classify whether the concern is north-south (external clients) or east-west (internal services).
Step 2
Place the gateway at the edge
Terminate external TLS, authenticate callers, and route or aggregate requests at a single entry point.
Step 3
Inject mesh sidecars
Deploy a proxy next to each service so the mesh can intercept all internal calls transparently.
Step 4
Configure the data plane
Define retries, timeouts, mTLS and traffic-splitting policies applied by the sidecars.
Step 5
Wire the control plane
Use the mesh control plane to push policy and collect telemetry across every proxy centrally.
What Interviewer Expects
- Clear north-south vs east-west distinction
- Understanding of the sidecar proxy pattern
- Awareness that they are complementary, not competing
- Knowledge of mTLS, retries and traffic shaping
- Recognition of the added operational complexity
Common Mistakes
- Claiming a service mesh replaces an API gateway
- Ignoring the resource overhead of sidecars
- Confusing the control plane with the data plane
- Thinking the mesh handles external authentication
Best Answer (HR Friendly)
“A service mesh manages how internal services talk to each other securely and reliably, while an API gateway is the front door that controls traffic coming in from outside. They work together rather than replacing one another.”
Code Example
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10Follow-up Questions
- What is the difference between the mesh data plane and control plane?
- How does a service mesh implement mutual TLS?
- Can you run an API gateway and a service mesh together?
- What overhead do sidecar proxies add?
- How does a mesh enable canary deployments?
MCQ Practice
1. A service mesh primarily manages which kind of traffic?
A service mesh governs internal, service-to-service (east-west) communication via sidecar proxies.
2. Where is an API gateway typically placed?
An API gateway sits at the system edge, handling external client-to-service traffic centrally.
3. Which capability is characteristic of a service mesh?
Service meshes transparently enforce mTLS, retries and traffic policies between internal services.
Flash Cards
North-south traffic — External client-to-service traffic, governed by an API gateway at the edge.
East-west traffic — Internal service-to-service traffic, governed by a service mesh via sidecars.
Sidecar proxy — A proxy deployed next to each service that intercepts its traffic for the mesh.
Are they competitors? — No — gateway controls the front door, mesh controls internal communication; they complement each other.
Continue Learning
Related Interview Questions
What is the difference between Istio and Linkerd as service meshes?
hard
What is the sidecar pattern and how is it used in microservices?
medium
How do you establish workload identity with mutual TLS, and what breaks when certificates rotate?
hard
How Would You Design a Service Mesh for Microservices?
hard