Part 5: Service Discovery - Complete Guide (Quick Reference)

Part 5: Service Discovery

How Microservices Find Each Other Dynamically - Quick Reference Guide

📌 Quick Summary (30 seconds):
Service Discovery solves the problem of dynamic IP addresses in cloud environments. Services register themselves on startup. Clients ask the registry "Where is Service X?" instead of using hardcoded IPs. Two patterns: Client-Side (client picks instance) and Server-Side (load balancer picks instance).

📊 How Service Discovery Works

Service Registration & Discovery Flow

┌─────────────┐ 1. Register ┌─────────────────┐
│ Payment │ ──────────────────► │ │
│ Service │ "I'm at :8080" │ SERVICE │
└─────────────┘ │ REGISTRY │
│ (Eureka/ │
┌─────────────┐ 2. Query │ Consul) │
│ Order │ ──────────────────► │ │
│ Service │ "Where is └─────────────────┘
└─────────────┘ Payment?" │
│ │ 3. Response
│ │ "10.0.0.5:8080"
│ ┌──────────────────────┘
│ ▼
│ ┌─────────────────┐
└────►│ Payment Service │
│ at :8080 │
└─────────────────┘

🎯 The Core Problem

❌ Without Service Discovery:

Hardcoded IP addresses in config files
When service restarts, IP may change → broken calls
Manual updates needed for every deployment
Cannot auto-scale (new instances have new IPs)
No load balancing across multiple instances

✅ With Service Discovery:

Services register automatically on startup
Clients discover services at runtime
Handles IP changes automatically
Supports auto-scaling seamlessly
Built-in load balancing

📋 Client-Side vs Server-Side Discovery

🖥️ Client-Side Discovery
Client picks which instance to call

Flow:
Client → Registry (get instances) → Client chooses → Calls instance

Tools:
Netflix Eureka + Ribbon, Consul

✅ Client has control over load balancing

✅ No extra hop (lower latency)

❌ Each client needs discovery logic

❌ Language-specific implementation

🌐 Server-Side Discovery
Load balancer picks the instance

Flow:
Client → Load Balancer → Registry → Balancer calls instance

Tools:
Kubernetes (kube-proxy), AWS ALB, NGINX

✅ Client just calls load balancer (simple)

✅ Language agnostic

❌ Extra network hop (slightly higher latency)

❌ Load balancer is extra component

🧩 Key Components

Component	What It Does	Real-World Analogy
Service Registry	Central database of all services and their locations. Stores Service Name → IP:Port mapping.	Phone Directory / Yellow Pages
Service Registration	Service tells registry "I'm alive and here is my address." Can be self-registration or via orchestrator.	Adding your name to a guest list
Service Discovery / Lookup	Client asks registry "Where is Service X?" and gets back list of available instances.	Asking reception "Where is Dr. Smith's office?"
Health Check	Registry periodically checks if services are still alive. Removes dead instances automatically.	Checking if a phone number still works
Load Balancer	Distributes requests across multiple instances of same service (Round Robin, Least Connections, etc.)	Restaurant host seating guests at available tables

🛠️ Popular Service Discovery Tools

Tool	Type	Key Features	Best For
Netflix Eureka	Client-Side	Self-registration, heartbeats, zone-aware routing	Spring Boot / Java microservices
HashiCorp Consul	Both	Multi-datacenter, health checks, key-value store	Multi-cloud deployments
Apache Zookeeper	Both	Distributed coordination, strong consistency	Kafka, legacy systems
Kubernetes (kube-dns / CoreDNS)	Server-Side	Built-in, service abstraction, environment variables	K8s native deployments
AWS Cloud Map	Both	AWS native, integrates with ALB, ECS, EKS	AWS environments

📝 Service Registration Patterns

🔵 Self-Registration

How: Service instance calls registry API to register itself on startup.

Health: Service sends periodic heartbeats.

✅ Simple, no extra components

❌ Couples service with discovery framework

Example: Eureka Client

🟢 Third-Party Registration

How: Orchestrator (Kubernetes) or service mesh registers services automatically.

Health: Platform monitors and updates registry.

✅ Service is decoupled, no code changes

❌ Requires orchestrator/platform support

Example: Kubernetes + CoreDNS

⚖️ Load Balancing Algorithms (Client-Side Discovery)

Algorithm	How It Works	Best For
Round Robin	Requests distributed in rotation: Instance A, B, C, A, B, C...	Similar instances, predictable distribution
Weighted Round Robin	Assign weights to instances (e.g., powerful instance gets more requests)	Heterogeneous instances (different capacities)
Least Connections	Send request to instance with fewest active connections	Long-running requests, variable processing time
Random	Pick random instance from the list	Simplest implementation, good enough for most
Consistent Hashing	Same user always goes to same instance (sticky sessions)	Session affinity needed

🌍 Zone / Region Aware Discovery

Cross-Zone Routing (Netflix Eureka style)

┌─────────────────────────────────────────────────────────────┐
│ US-EAST Region │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Zone A │ │ Zone B │ │ Zone C │ │
│ │ Order: 3 │ │ Order: 2 │ │ Order: 1 │ │
│ │ Payment: 2 │ │ Payment: 2 │ │ Payment: 1 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ Zone-Aware Client prefers same zone │
│ to reduce latency and costs │
└─────────────────────────────────────────────────────────────┘

💡 Zone-Aware Routing Rules:

Prefer instances in same zone (lower latency, no cross-zone cost)
If no healthy instances in same zone, fallback to other zones
Netflix Eureka: Ribbon with ZonePreferenceServerListFilter

📊 Tool Comparison Matrix

Feature	Eureka	Consul	Kubernetes	Zookeeper
CAP Trade-off	AP (Availability)	CP (Consistency)	AP	CP
Health Checking	Client heartbeat	Client + server	Pod liveness	Ephemeral nodes
Multi-datacenter	Yes (limited)	Yes (native)	No	Yes
Key-Value Store	No	Yes	Yes (ConfigMap)	Yes
Service Mesh	No	Yes (Consul Connect)	Yes (Istio)	No

⚡ Pros & Cons Summary

✅ ADVANTAGES
• No hardcoded IP addresses
• Seamless auto-scaling
• Self-healing (dead instances removed)
• Load balancing built-in
• Zone/region aware routing
• Canary deployments support

❌ DISADVANTAGES / CHALLENGES
• Additional infrastructure complexity
• Registry is a single point of failure (if not clustered)
• Network latency for discovery calls
• Caching can lead to stale data
• Client-side logic needed (for client-side pattern)
• Learning curve for new team members

💡 Interview Power Phrases

"Service discovery enables dynamic routing in cloud environments. Services register on startup, and clients discover them at runtime - no hardcoded IP addresses needed."

"We use client-side discovery with Eureka for fine-grained load balancing control, and server-side discovery with Kubernetes for simplicity in containerized environments."

"The registry must be highly available. We run a cluster with multiple nodes and use health checks to automatically remove unhealthy service instances."

"Zone-aware routing reduces cross-zone latency and cloud costs by preferring service instances in the same availability zone as the caller."

📚 Quick Memory Reference

🔑 Key Terms

Service Registry - Phone directory of services
Registration - "I'm alive at this address"
Discovery - "Where is Service X?"
Health Check - Heartbeat / Keep-alive
Load Balancer - Traffic distributor

🧠 Mental Models

Service Discovery = Google Maps for microservices
Registry = Phone Directory / Yellow Pages
Registration = Adding name to guest list
Health Check = Security guard checking badges
Load Balancer = Restaurant host seating guests

📌 One-Line Summary

"Service Discovery lets services find each other without hardcoded addresses - essential for cloud and Kubernetes environments."

✅ Key Takeaways (Remember These 5 Points)

Why needed: Cloud services have dynamic IPs that change on restart/scale
Two patterns: Client-Side (client picks) vs Server-Side (load balancer picks)
Key components: Registry, Registration, Discovery, Health Check
Popular tools: Eureka, Consul, Kubernetes CoreDNS, Zookeeper
Zone awareness: Prefer same zone for lower latency and cost

🎯 Remember This:
Without Service Discovery → Hardcoded IPs → Broken calls on restart
With Service Discovery → Services find each other → Resilient and scalable