Revision: Cheat Sheet and Self-Check

Cheat sheet

Concepts: gateway = north-south edge policy; mesh = east-west with sidecar data plane + control plane; reverse proxy/LB/Ingress/Gateway API fit around them. Routing: path/host/header, prefix stripping, request ID, weighted canary (9:1 gave 90/10), header opt-in. Security: 401 vs 403, API keys vs JWT/OAuth, token-bucket rate limits with 429 + Retry-After, TLS termination, WAF, CORS. Resilience: explicit shrinking timeouts (504), retries only idempotent and at one layer (amplification 3, 9, 27, 81), circuit breaker closed/open/half-open, outlier detection, least-load and consistent hashing. Mesh: mTLS workload identity, default-deny authz, policy as YAML, golden signals + trace propagation. Ops: thin gateway, HA across zones, config as code + validation, staged upgrades, bypass, failure drills. Delivery: shadow, canary, blue-green, automated promotion.

Questions interviewers ask

Be ready to explain: the difference between an API gateway and a service mesh, what a sidecar does, how mTLS works and why short-lived certificates help, how you would implement a canary, how retries can cause a retry storm and how to prevent it, how a circuit breaker works, and when you would not adopt a mesh.

Quick check: A downstream service is failing. Calls pile up and the gateway runs out of connections. Which combination helps most?

• Timeouts plus a circuit breaker with a fallback
• Longer timeouts and more retries
• Disable health checks
• Remove rate limits

Quick check: Why is `hash(key) % N` a poor way to pick a cache server when N changes?

• It makes keys longer
• It is too slow to compute
• It is illegal
• Most keys map to a different server, causing mass cache misses

Quick check: What does a mesh need so that services can trust the identity of callers?

• Shared passwords in code
• mTLS with workload certificates issued by the mesh CA
• IP address allow-lists only
• Longer DNS names