Service Discovery
Lets services find each other’s network locations dynamically as instances scale up, down, or move.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Service Discovery is non-negotiable.
① What it is (30 seconds)
Lets services find each other’s network locations dynamically as instances scale up, down, or move.
② How it works in system design
Services register name + IP/port with a registry (Consul, etcd, Kubernetes DNS). Clients resolve logical name → current instance list. Health checks deregister dead nodes.
Typical placement
Client→Edge / Gateway→Service→Services→Data stores
③ Concrete system design example
Scenario: Payment service scales from 3 to 30 pods during Black Friday. Order service resolves
payment-svc via K8s DNS and gets updated endpoints without config change.④ Important interview Q&A
| Question | Answer |
|---|---|
| Client-side vs server-side discovery? | Client pulls registry and picks instance (Eureka) vs client always hits LB that knows backends (K8s Service). |
| Why not static IPs? | Auto-scaling and failures change IPs constantly in cloud. |
| Split brain in registry? | Use consensus stores (etcd) or K8s control plane; avoid single-node registry. |
⑤ Seen in these system designs
- Uber / Rides — many microservices
- Task Scheduler — worker pool discovery
- Google Real-time Analytics — fleet of collectors
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Registry choice
- Health-based deregistration
- DNS vs sidecar
- Cache TTL on clients