Back to roadmap
Module 5 · APIs & Application LayerDay 04825 min

Service Discovery and Service Mesh

How services find each other — and how the mesh helps.

Day 048

Service Discovery and Service Mesh

App A
service
Sidecar
edge
Sidecar
edge
App B
service
Signal path
Sidecar mesh
App A
service
flow
Sidecar
edge
Sidecar
edge
mTLS
Sidecar
edge
Sidecar
edge
flow
App B
service
Memory hook

Service Discovery and Service Mesh: how services find each other

Mental model

turn boundaries into contracts

Design lens

Mesh adds ~1ms latency per hop.

Recall anchors
DiscoveryMesh

Why it matters

Service discovery solves 'where is service X right now?'. DNS-based works for stable, slow-changing fleets. Registry-based (Consul, Eureka, Kubernetes endpoints) handles dynamic fleets and per-instance health.

Deep dive

Service mesh adds a sidecar per service handling discovery, retries, mTLS, telemetry, traffic shaping.

Mesh trades simplicity for uniform observability and policy. Operationally heavy if you're small.

Lightweight alternative: client libraries with retries + tracing + JWT, no sidecar.

Demo / scenario

Add a service mesh to existing microservices.

  1. Inject Envoy sidecar in every pod.
  2. Sidecar handles mTLS + retries.
  3. Apply a fault-injection rule for chaos testing.
  4. Get uniform metrics across services for free.

Tradeoffs

  • Mesh adds ~1ms latency per hop.
  • Operational footprint nontrivial.
  • Skip mesh below ~20 services — libraries cover it.

Diagram

mTLS
App A
Sidecar
Sidecar
App B
Sidecar mesh.

Mind map

Check yourself

Loading quiz…

Sources & further reading