API Gateway & Service Mesh
Master the API Gateway pattern (routing, auth, rate limiting, SSL termination), understand Service Mesh with sidecar proxies (Istio, Envoy, Linkerd), East-West vs North-South traffic, mTLS between services, and when to use each.
Master the API Gateway pattern (routing, auth, rate limiting, SSL termination), understand Service Mesh with sidecar proxies (Istio, Envoy, Linkerd), East-West vs North-South traffic, mTLS between services, and when to use each. This hands-on tutorial focuses on practical implementation of api gateway & service mesh concepts.
API Gateway & Service Mesh
As your microservices multiply, two infrastructure problems emerge: (1) How do external clients discover and access your many services? (2) How do services communicate with each other securely and reliably? The API Gateway solves the first; the Service Mesh solves the second.
[!IMPORTANT] An API Gateway is the front door to your system — all external traffic enters through it. A Service Mesh is invisible infrastructure between services — handling internal service-to-service communication. You typically need both in a mature microservices deployment.
API Gateway
Service Mesh
A Service Mesh injects a sidecar proxy (Envoy) next to each service. All network traffic flows through the sidecar. This offloads cross-cutting concerns (mTLS, retries, circuit breaking, observability) from application code:
| Feature | Without Service Mesh | With Service Mesh (Istio/Linkerd) |
|---|---|---|
| mTLS | Manual certificate management per service | Automatic — Citadel provisions and rotates certs |
| Retries | Code in every service | Configured once in VirtualService |
| Circuit breaking | Library in every service | Configured in DestinationRule |
| Observability | Each service manually instruments | Automatic traces/metrics for every call |
| Traffic splitting | Complex code change | 1-line config (90% v1, 10% v2) |
| Zero-trust | Hard to enforce | Enforced by default (deny-all, allow specific) |
Quiz
Quiz
Question 1 of 2You have 15 microservices. Every service needs to implement rate limiting, JWT authentication, and request logging. What is the correct approach?
Key Takeaways
✅ API Gateway = single entry point for all external traffic; handles auth, rate limiting, routing, SSL termination.
✅ Service Mesh = infrastructure for internal service-to-service traffic; handles mTLS, retries, circuit breaking, observability.
✅ North-South traffic = external → services (API Gateway's domain). East-West traffic = service → service (Service Mesh's domain).
✅ Sidecar proxy (Envoy) is injected alongside each service pod; all traffic flows through it — application code is unmodified.
✅ Use AWS API Gateway / Kong / Nginx for the gateway; Istio / Linkerd for service mesh in Kubernetes.
Official Resources
- 📖 Kong API Gateway — Popular open-source API Gateway
- 📖 AWS API Gateway — Managed API Gateway on AWS
- 📖 Istio Documentation — Most widely used service mesh
- 📖 Envoy Proxy — The sidecar proxy powering most service meshes
What's Next?
With traffic managed, how do services find each other dynamically as instances start and stop?
Next: Service Discovery & Configuration Management — Consul, etcd, blue-green deployments, and feature flags.