What is Service Discovery?
Service Discovery is how services in a distributed system automatically find and talk to each other. Instead of hardcoding addresses like "call the payment service at 192.168.1.5:8080", services ask a registry "where's the payment service?" and get back the current address. When services scale up, move, or crash, the registry keeps track so everyone knows where to go.
Think of it like: A phone book that updates itself automatically. When someone changes their number, everyone can still reach them.
The Problem: Hardcoded Addresses
Without Service Discovery
Services have hardcoded addresses:
Payment service moves to new server
↓
Other services still call old address
↓
Everything breaks!
Solution? Update config files and restart all services. Manual and slow.
With Service Discovery
Services look up addresses dynamically:
Payment service moves to new server
↓
Registry updates automatically
↓
Services find new address!
Result: No manual updates. Everything just works.
How Service Discovery Works
sequenceDiagram
participant OrderService
participant Registry
participant PaymentService
Note over PaymentService: Starts up
PaymentService->>Registry: Register at 10.0.1.5:8080
Registry-->>PaymentService: Registered
Note over OrderService: Needs to process payment
OrderService->>Registry: Where is payment service?
Registry-->>OrderService: 10.0.1.5:8080
OrderService->>PaymentService: Process payment
PaymentService-->>OrderService: Payment successful
Note over Registry: Sends health checks
Registry->>PaymentService: Are you alive?
PaymentService-->>Registry: Yes, still here
Key Benefits
Automatic Updates
Services register themselves on startup and deregister on shutdown. No manual configuration files to update when things change.
Health Checks
The registry constantly checks if services are healthy. Dead instances get removed automatically so traffic only goes to working services.
Easy Scaling
Spin up 10 more instances of a service and they all register automatically. Load gets distributed across all healthy instances.
Discovery Patterns
Client-Side Discovery
The client looks up the service address from the registry and calls it directly.
Server-Side Discovery
Client calls a load balancer, which looks up the service and forwards the request.
Client-Side vs Server-Side
graph TB
subgraph Client-Side Discovery
A1[Order Service] --> B1[Registry]
B1 --> A1
A1 --> C1[Payment Service A]
A1 --> D1[Payment Service B]
end
subgraph Server-Side Discovery
A2[Order Service] --> E2[Load Balancer]
E2 --> B2[Registry]
B2 --> E2
E2 --> C2[Payment Service A]
E2 --> D2[Payment Service B]
end
style A1 fill:#e0f2fe,stroke:#0369a1,stroke-width:2px
style A2 fill:#e0f2fe,stroke:#0369a1,stroke-width:2px
style B1 fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
style B2 fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
style E2 fill:#f3e8ff,stroke:#a855f7,stroke-width:2px
style C1 fill:#dcfce7,stroke:#16a34a,stroke-width:2px
style D1 fill:#dcfce7,stroke:#16a34a,stroke-width:2px
style C2 fill:#dcfce7,stroke:#16a34a,stroke-width:2px
style D2 fill:#dcfce7,stroke:#16a34a,stroke-width:2px
Popular Tools
- Consul: Full-featured service mesh with discovery, health checks, and key-value store. Works everywhere.
- Eureka: Netflix's discovery service. Popular in Spring Boot apps. Simple and battle-tested.
- Kubernetes: Built-in service discovery via DNS. Services find each other by name automatically.
- Zookeeper: Old-school but solid. Used by Kafka and many Apache projects for coordination.
