Service Discovery
In microservices architectures with dynamic scaling (containers, Kubernetes), services come and go constantly.
Quick answer: Service Discovery
Service Discovery is covered here as a practical system design concept. In microservices architectures with dynamic scaling (containers, Kubernetes), services come and go constantly. Use it to understand the Distributed Systems idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
The Core Idea
Service discovery is the mechanism by which services in a distributed system find and communicate with each other. Instead of hardcoding IP addresses, services register themselves with a discovery service and query it to find other services.
Step-by-Step Walkthrough
When Service A starts, it registers itself with the service registry (e.g., Consul): 'I am ServiceA, running at 10.0.1.5:8080.' When Service B needs to call Service A, it queries the registry: 'Where is ServiceA?' The registry returns [10.0.1.5:8080, 10.0.1.6:8080]. Service B picks one and makes the call.
In Kubernetes, this is handled automatically: creating a Service object creates a DNS entry and virtual IP that load balances across pods.
Why This Approach Wins
- Service registry: A central database of service instances and their network locations (Consul, etcd, ZooKeeper, Eureka).
- Client-side discovery: The client queries the registry and load balances across instances (Netflix Eureka + Ribbon).
- Server-side discovery: A load balancer queries the registry and routes requests (AWS ALB, Kubernetes Service).
- DNS-based discovery: Services register DNS records. Clients resolve DNS to find instances (Consul DNS, Kubernetes CoreDNS).
- Health checking: The registry removes unhealthy instances so clients do not route to dead services.
In Production
Netflix uses Eureka for service discovery across thousands of microservices in AWS.
Kubernetes uses etcd as its service registry, with CoreDNS for DNS-based discovery and kube-proxy for load balancing.
HashiCorp Consul provides service discovery with health checking, used by companies like Stripe and Twitch.
Tradeoffs and Limitations
- Client-side vs Server-side: Client-side is more flexible but couples clients to the registry. Server-side is simpler for clients.
- Consistency vs Availability: The registry must be highly available; if it goes down, services cannot find each other.
- Push vs Pull: Registry pushes updates (faster) or clients poll (simpler but delayed).
Production Gotchas
- Making the service registry a single point of failure
- Not implementing health checks — dead instances remain in the registry
- Hardcoding service addresses instead of using discovery
The Interview Angle
- How does service discovery work?
- What is the difference between client-side and server-side discovery?
- How does Kubernetes handle service discovery?
- What happens when a service instance fails?
Next Up
Original DosiBridge notes for Service Discovery
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Service Discovery is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Membership: For Service Discovery, decide the membership before choosing tools; otherwise the design looks clean but fails when service changes.
- Clock Drift: For Service Discovery, decide the clock drift before choosing tools; otherwise the design looks clean but fails when discovery changes.
- Retry Semantics: For Service Discovery, decide the retry semantics before choosing tools; otherwise the design looks clean but fails when service changes.
- Partition Behavior: For Service Discovery, decide the partition behavior before choosing tools; otherwise the design looks clean but fails when discovery changes.
- Reconciliation: For Service Discovery, decide the reconciliation before choosing tools; otherwise the design looks clean but fails when service changes.
Production review question
If a team adopts Service Discovery, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track service-discovery health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Service Discovery, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.