Implementing Service Discovery Patterns
1. Client-Side Discovery Pattern
| Aspect | Detail |
|---|
| Mechanism | Client queries registry, picks instance, calls directly |
| Load Balancing | Client-side (round-robin, least-conn) |
| Pros | No extra hop; smart client decisions |
| Cons | Logic in every client lib; multi-language overhead |
| Tools | Eureka + Ribbon, Consul |
2. Server-Side Discovery Pattern
| Aspect | Detail |
|---|
| Mechanism | Client → Load Balancer → service instance |
| LB Updates | LB queries registry or consumes service events |
| Pros | Clients dumb; central control |
| Cons | Extra hop; LB itself must HA |
| Examples | K8s Service + kube-proxy, AWS ELB, Envoy |
3. Service Registry Pattern
| Stored Per Instance | Detail |
|---|
| Service Name | Logical identifier |
| Network Address | IP + port |
| Health | UP / DOWN / DRAINING |
| Metadata | Version, region, zone, weight |
| TTL | Auto-expiry without heartbeat |
| Tools | Consul, etcd, ZooKeeper, Eureka, K8s API |
4. Self-Registration Pattern
| Step | Action |
|---|
| Startup | Service registers itself with registry |
| Heartbeat | Periodic keep-alive |
| Shutdown | Deregister gracefully (PreStop hook) |
| Pros | Service knows its own state |
| Cons | Registration code in every service |
5. Third-Party Registration Pattern
| Aspect | Detail |
|---|
| Mechanism | Registrar (separate process) registers service on its behalf |
| Examples | Kubernetes (kubelet), Registrator for Docker |
| Pros | Service code unaware; cleaner SoC |
| Cons | Registrar is another moving part |
6. Health Check Pattern
| Probe | Purpose |
|---|
| Liveness | "Am I alive?" — restart if not |
| Readiness | "Can I serve traffic?" — remove from LB if not |
| Startup | "Have I finished booting?" — defer other probes |
| Deep Health | Checks dependencies; for ops only, not LB |
Example: Spring Boot Actuator
management:
endpoint.health.probes.enabled: true
endpoints.web.exposure.include: health,info,metrics
health.livenessstate.enabled: true
health.readinessstate.enabled: true
Warning: Don't include downstream service status in liveness probe — one downstream outage will restart all your pods, amplifying the failure.
7. DNS-Based Discovery Pattern
| Aspect | Detail |
|---|
| Mechanism | DNS A/SRV records map service name to IPs |
| K8s Example | order-svc.default.svc.cluster.local |
| Pros | Universal client support |
| Cons | TTL caching delays updates; no health awareness in plain A records |
| Metadata Key | Use |
|---|
| version | Canary / blue-green routing |
| region / zone | Locality-aware routing |
| capabilities | Feature-flag-aware routing |
| weight | Weighted load balancing |
| tenant | Multi-tenant isolation |
9. Lease Pattern
| Aspect | Detail |
|---|
| Definition | Time-bound registration; must renew before expiry |
| Expiry | Registry auto-removes stale instances |
| Benefit | Self-healing against dead instances that didn't deregister |
| Tuning | Lease TTL = 2-3× heartbeat interval |
10. Heartbeat Pattern
| Aspect | Detail |
|---|
| Mechanism | Service sends periodic ping to registry |
| Interval | Typically 5-30s |
| Missed Heartbeats | N consecutive missed → mark DOWN |
| Combine With | Lease TTL for self-healing |