Module 5 - Architecture Patterns

Service Discovery

How services find each other in a dynamic microservices environment.

1The Phone Directory Analogy

Simple Analogy

Before cell phones, you'd look up a business in the phone book. The book was updated regularly with new numbers. Service discovery is like a constantly-updated phone book for your microservices-it knows where everyone is right now.

Service Discovery automatically detects and tracks the network locations (IP:port) of service instances as they start, stop, or move.

2Why It's Needed

Dynamic IPs

Cloud instances get new IPs on restart. Hardcoding doesn't work.

Auto-scaling

Instances come and go. Discovery tracks current healthy instances.

Containers

Kubernetes pods are ephemeral. IP changes on every restart.

Load Balancing

Need to know all instances to distribute traffic.

3Discovery Patterns

Client-Side Discovery

Client queries registry, picks an instance, calls directly.

Example: Netflix Eureka + Ribbon

Server-Side Discovery

Client calls load balancer, which queries registry.

Example: AWS ELB, Kubernetes

4Popular Solutions

Consul

HashiCorp. Service mesh, health checks, key-value store.

etcd

Distributed key-value store. Powers Kubernetes.

Eureka

Netflix OSS. Java-focused, self-preserving.

Kubernetes DNS

Built-in discovery via DNS and Services.

5Key Takeaways

1Service Discovery tracks where service instances are running

2Essential when IPs are dynamic (cloud, containers, auto-scaling)

3Client-side: client picks instance. Server-side: load balancer picks.

4Health checks ensure only healthy instances receive traffic

5Popular: Consul, etcd, Kubernetes DNS, Eureka

?Quiz

1. Your Kubernetes pod restarts. Why is hardcoded IP a problem?

2. In client-side discovery, who picks which instance to call?