Service Discovery

In microservices, services need to find each other dynamically.

The Problem

Without Service Discovery:

Service A needs to call Service B

Problem: Where is Service B?
- IP addresses change
- Containers scale up/down
- Services deploy to different hosts
- Multiple instances of same service

Hardcoded:
Service A → http://10.0.0.5:8080/api/data

Problem: If Service B moves to 10.0.0.6, A breaks!

Service Discovery Solution

With Service Discovery:

1. Service B registers with discovery service
   Service B → Discovery: "I'm at 10.0.0.5:8080"

2. Service A queries discovery service
   Service A → Discovery: "Where is Service B?"
   Discovery → Service A: "10.0.0.5:8080"

3. Service A calls Service B
   Service A → 10.0.0.5:8080

Benefits:
- Services can move freely
- Automatic load balancing
- Health checking
- Dynamic scaling

Discovery Patterns

1. Client-Side Discovery
   Client queries registry, gets instance list
   Client picks instance and connects

2. Server-Side Discovery
   Client connects to router/load balancer
   Router queries registry, routes request

3. DNS-Based Discovery
   Service registered as DNS record
   Client resolves DNS to get instance

DNS-based discovery uses DNS records to locate services.

How DNS Discovery Works

1. Service registers DNS record
   user-service → 10.0.0.1:8080
   user-service → 10.0.0.2:8080

2. Client queries DNS
   client → DNS: "Where is user-service?"
   DNS → client: "10.0.0.1, 10.0.0.2"

3. Client connects
   client → 10.0.0.1:8080 (or round robin)

DNS Record Types

Type	Use Case	Example
A	IPv4 address	user-service → 10.0.0.1
AAAA	IPv6 address	user-service → ::1
SRV	Service with port	_http._tcp.user-service
CNAME	Alias	api.example.com → lb.example.com

SRV Records

SRV Record Format:
_service._proto.name. TTL class SRV priority weight port target

Example:
_http._tcp.user-service. 300 IN SRV 10 60 8080 host1.example.com.
_http._tcp.user-service. 300 IN SRV 10 40 8080 host2.example.com.

Client can discover:
- Service name
- Port number
- Priority and weight for load balancing

DNS Discovery Tools

- Consul (HashiCorp)
  - Built-in DNS server
  - Health checking
  - KV store

- Kubernetes DNS
  - CoreDNS
  - Automatic service discovery
  - Headless services for stateful

- AWS Cloud Map
  - Managed service discovery
  - DNS and API-based

DNS Discovery Limitations

1. TTL Caching
   - Clients cache DNS responses
   - Slow to detect changes

2. No Health Checking
   - DNS doesn't check if service is healthy
   - May route to dead instances

3. Limited Load Balancing
   - Basic round-robin only
   - No sophisticated algorithms

DNS + Health Check

Solution: DNS with health checking

1. Health checker monitors services
2. Unhealthy services removed from DNS
3. Client always gets healthy instances

Tools:
- Consul: DNS + health checks
- Kubernetes: Readiness probes + DNS

Registry-based discovery uses a central service registry.

How Registry Works

1. Service Registration
   Service B → Registry: "I'm at 10.0.0.5:8080, health: /health"

2. Service Query
   Service A → Registry: "Give me instances of Service B"
   Registry → Service A: [{ip: 10.0.0.5, port: 8080}, ...]

3. Load Balancing
   Service A picks instance from list
   Connects directly to Service B

Registry Architecture

┌─────────────────────────────────────────┐
│              Service Registry            │
│                                         │
│  Services:                              │
│  ├── user-service: [10.0.0.1, 10.0.0.2]│
│  ├── order-service: [10.0.0.3]          │
│  └── pay-service: [10.0.0.4, 10.0.0.5] │
│                                         │
│  Health Checks:                         │
│  ├── user-service: healthy              │
│  ├── order-service: healthy             │
│  └── pay-service: unhealthy (10.0.0.5)  │
└─────────────────────────────────────────┘

Registry Tools

Tool	Type	Features
Consul	Dedicated	DNS, HTTP, health checks, KV
etcd	Key-value	Strong consistency, Raft
ZooKeeper	Coordination	Leader election, locks
Eureka	Netflix	REST-based, eventual consistency

Consul Example

# Service registration
service {
  name = "user-service"
  port = 8080
  tags = ["v1", "production"]
  check {
    http = "http://localhost:8080/health"
    interval = "10s"
    timeout = "3s"
  }
}

# Service discovery
GET /v1/catalog/service/user-service

Client-Side vs Server-Side Discovery

Aspect	Client-Side	Server-Side
Who discovers	Client	Router/LB
Who load balances	Client	Router/LB
Latency	Lower (direct)	Higher (extra hop)
Complexity	Client library needed	Centralized

Best Practices

1. Health checking: Always verify service health
2. Multiple registries: Avoid single point of failure
3. Caching: Cache registry responses locally
4. Timeouts: Set appropriate timeouts
5. Monitoring: Monitor registry health