Service Discovery Pattern

Service Discovery enables services to register themselves and discover other services dynamically, removing the need to hardcode IPs/ports/URLs.

Two Roles:

1. Service Registry: A central database that tracks service instances (e.g., Eureka, Consul, etcd)
2. Service Client:
   • Register itself with the registry (if it’s a server)
   • Query registry to find other services (if it’s a consumer)

When to Use It

You need Service Discovery when:

Situation	Why You Need It
Services scale dynamically	Their IPs/ports change frequently
You deploy in cloud/Kubernetes	Pods and containers are ephemeral
You want resilience + flexibility	Avoid hardcoded URLs
You want load-balanced discovery	Integrate with client-side LB

Service Discovery Options

Tool	Use Case
Eureka	Spring Cloud / Netflix stack
Consul	Multi-platform, key-value + health
Kubernetes DNS	Built-in DNS-based discovery
AWS Cloud Map	AWS

Summary

Component	Role
Eureka Server	Service Registry
Eureka Client	Registers with and queries Eureka
LoadBalancer (Ribbon or Spring LB)	Chooses instance
RestTemplate / Feign	Makes the call

When to Use Service Discovery

Scenario	Use Discovery?
Dynamic microservices (cloud)	✅ Yes
Monolith or fixed deployment	❌ No
Containerized (K8s, ECS) apps	✅ Yes
Static VM-based architecture	❌ Often not