Module 5 — Architecture

Service Discovery

How services find each other in a dynamic, distributed environment.

1The Phone Directory Analogy

💡 Simple Analogy
Before cell phones, you looked up numbers in a phone book. The phone book was updated periodically with new numbers and removed disconnected ones.

Service discovery is like a dynamic phone book for services. Services register themselves when they start and deregister when they stop.

2The Problem

In dynamic environments, service locations change constantly:

Auto-scaling adds/removes instances
Containers get new IPs on restart
Deployments roll out new versions
Failures require routing around dead instances

Hardcoded IPs don't work. You need dynamic discovery.

3Discovery Patterns

Client-Side Discovery

Client queries registry, then calls service directly.

Client → Registry: Where is Service A?
Registry → Client: 10.0.0.5:8080
Client → Service: Direct call
Pro: Client can do smart load balancing
Con: Discovery logic in every client

Server-Side Discovery

Client calls load balancer, which handles discovery.

Client → Load Balancer: Request
LB → Registry: Where is Service A?
LB → Service: Forwards request
Pro: Clients are simple
Con: Extra hop through LB

4Service Registry

A Service Registry is a database of available service instances. Services register on startup, deregister on shutdown, and send heartbeats to prove they're alive.
ToolTypeFeatures
ConsulService MeshHealth checks, KV store, multi-DC
etcdKV StoreKubernetes backend, strong consistency
ZooKeeperCoordinationLeader election, config, Netflix stack
Kubernetes DNSBuilt-inservice.namespace.svc.cluster.local

5Key Takeaways

1Service discovery allows services to find each other dynamically.
2Services register/deregister and send heartbeats.
3Client-side: client does discovery. Server-side: LB does it.
4Kubernetes handles discovery with DNS and Services.
5Consul, etcd are common for non-K8s environments.
6In interviews: explain registration, health checks, and failover.