Explain Service Mesh vs Ingress in Kubernetes.

In Kubernetes, Ingress manages external (north–south) traffic into the cluster, while a Service Mesh manages internal (east–west) service-to-service communication, security, and observability.

When to Use

• Ingress:

  • Exposing services publicly
  • TLS termination
  • Routing based on host/path

• Service Mesh:

  • Secure internal traffic with mTLS
  • Retries, timeouts, and circuit breaking
  • Traffic shifting for canary/blue-green deployments
  • Deep observability and telemetry

Example

A user’s request hits /api through Ingress. Inside the cluster, checkout calls payments via the mesh (e.g., Istio/Linkerd) with retries and encryption to ensure reliability.

Want to go deeper?

Explore:

• Grokking System Design Fundamentals
• Grokking the System Design Interview
• Grokking Database Fundamentals for Tech Interviews
• Grokking the Coding Interview
• Mock Interviews with ex-FAANG engineers

Why Is It Important

Separating edge traffic (Ingress) from internal communication (Service Mesh) helps scale microservices safely, enforce security, and improve uptime with controlled rollout strategies.

Interview Tips

• Start with the one-liner definition.
• Explain north–south vs. east–west traffic.
• Mention mesh features: mTLS, retries, observability.
• Add that many companies begin with Ingress and adopt a mesh at scale.

Trade-offs

• Service Mesh: Pros: Security, Resilience, and Visibility | Cons: Complexity and Latency overhead
• Ingress: Pros: Simplicity and Low cost | Cons: No fine-grained traffic policies

Pitfalls

• Mistaking Ingress for a full API gateway + mesh solution
• Enabling all mesh features too early
• Forgetting consistent mTLS and retry policies