Gateway vs
Service Mesh
Managing North-South traffic (Clients to Servers) vs East-West traffic (Server to Server).
Architectural Strategy
In a distributed system, communication is the biggest overhead. The question is: Where do the cross-cutting concerns (Auth, Retry, Observability) live?
The Central Gateway
North-South Focus
Designed to handle requests coming into your data center. It's the "Front Door".
• Handles JWT verification for mobile/web apps.
• Protocol translation (HTTP/2 to internal gRPC).
• SSL Termination at the edge.
"See Phase 2: API Gateways for the technical implementation of rate-limiting and routing."
The Service Mesh (Istio/Linkerd)
East-West Focus
Designed to handle requests between your microservices. It uses a **Sidecar Proxy** (Envoy) attached to every service instance.
• mTLS: Automatic encryption between services.
• Retries: Intelligent retry logic without changing app code.
• Shadowing: Mirroring traffic to test new versions.
Symmetry of Concerns: Comparison
| Feature | API Gateway | Service Mesh |
|---|---|---|
| Traffic Direction | North-South | East-West |
| Deployment | Centralized / Cluster | Sidecar per service |
| Authentication | JWT / API Keys | mTLS / Spiffe |
| Responsibility | Business / Products | Networking / Operations |
| Performance | Single point latency | Distributed overhead |
Interview Guidance
"When would you use both?"
In a mature enterprise, you use an API Gateway (Kong) to expose your product to the world and a **Service Mesh** (Istio) to manage the internal spaghetti of 100+ microservices.
The "Complexity" Warning
Don't start with a Service Mesh. It adds massive operational overhead. In an interview, always mention that "A Service Mesh is for Day 2 operations, not Day 1."