Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Service discovery is a fundamental mechanism in distributed systems that allows services to find and communicate with each other without hardcoding network locations. In 2026, as microservices architectures scale to thousands of ephemeral nodes, automated service discovery is non-negotiable for system reliability. Interviewers ask about service discovery to evaluate your understanding of network topology, consistency models, and the trade-offs between centralized and decentralized control. Junior candidates are expected to understand the basic 'registry' pattern and how clients resolve service addresses. Senior candidates must demonstrate mastery over consistency trade-offs (CAP theorem in the context of registries), handling network partitions, health check propagation, and the implementation of service meshes versus traditional load balancer-based discovery.
In modern cloud-native environments, IP addresses are dynamic and ephemeral. Hardcoding endpoints leads to brittle systems that fail during auto-scaling events or rolling deployments. Service discovery provides the 'source of truth' for network topology. By decoupling service location from service identity, organizations can achieve zero-downtime deployments and resilient failover. This topic is a high-signal interview area because it forces candidates to reconcile the theoretical CAP theorem with practical engineering constraints. A strong answer demonstrates awareness of the 'stale read' problem in distributed registries and the latency impact of discovery lookups. In 2026, with the rise of service meshes like Istio, the conversation has shifted from simple registry lookups to sidecar-based traffic management, making the distinction between control plane and data plane discovery crucial for senior roles.
Service discovery architectures typically separate the control plane (registry) from the data plane (clients/load balancers). When a service starts, it registers its metadata with the registry. The registry performs health checks to ensure the service is responsive. Clients or load balancers then query the registry to resolve service names to IP addresses.
[Service Instance]
↓ (Register)
[Service Registry] ← [Health Checker]
↑ (Query)
[Client/Load Balancer]
↓ (Route)
[Target Instance]Deploying a proxy (e.g., Envoy) alongside the service to handle discovery lookups and load balancing.
Trade-offs: Reduces application complexity but increases resource overhead per pod.
Clients cache registry lookups locally with a TTL to reduce load on the registry and improve latency.
Trade-offs: Risk of routing to stale endpoints if registry updates are not propagated instantly.
Instances share membership information with peers via epidemic broadcast, eliminating a central registry.
Trade-offs: High scalability and no single point of failure, but eventual consistency is harder to reason about.
| Reliability | Use multi-region registry deployments and client-side caching to survive registry outages. |
| Scalability | Use gossip protocols for large clusters to avoid central registry bottlenecks. |
| Performance | Minimize lookup latency by using local sidecars or persistent gRPC streams for registry updates. |
| Cost | Registry nodes consume CPU/RAM; scale registry clusters based on service count, not just traffic. |
| Security | Implement mTLS for service registration and query APIs to prevent unauthorized service spoofing. |
| Monitoring | Track 'registry lookup latency', 'stale endpoint count', and 'heartbeat failure rate'. |
Service discovery is the process of finding the network locations (IPs/ports) of available service instances. Load balancing is the process of distributing traffic across those discovered instances. Discovery provides the list of targets; load balancing determines which target receives the next request.
DNS is simple and ubiquitous but often problematic for high-scale microservices due to aggressive client-side caching and slow propagation of updates. While suitable for static environments, dynamic cloud-native systems usually require specialized registries like Consul or Kubernetes DNS for faster, more reliable updates.
A service registry is a database that stores the network locations and metadata of service instances. It acts as the 'source of truth' for the system's topology, allowing services to find each other dynamically.
Health checks are necessary to detect when a service instance has crashed or become unresponsive. Without them, the registry would continue to return addresses of dead nodes, leading to failed requests and system instability.
Service registries must choose between Consistency and Availability during network partitions. A strongly consistent registry (like one based on Raft) might become unavailable during a partition, while an eventually consistent registry (like one using gossip) remains available but might return stale data.
In client-side discovery, the client queries the registry and chooses the instance to call. In server-side discovery, the client calls a load balancer, which queries the registry and routes the request. Client-side offers more control; server-side offers simpler client logic.
A sidecar proxy (like Envoy) is a small process deployed alongside each service instance. It handles discovery lookups, health checking, and load balancing, offloading these complex tasks from the application code.
Service discovery handles scaling by automatically registering new instances as they come online and deregistering them as they scale down. This allows the system to maintain an accurate, real-time view of available capacity without manual configuration.
A zombie service is an instance that has crashed or been terminated but remains in the service registry. This happens if the instance fails to send a deregistration signal and the registry lacks an active health-checking mechanism to clean it up.
Use a service mesh when you need advanced traffic management (canary, circuit breaking, mTLS) across a large number of microservices. It abstracts discovery and communication, making it ideal for complex, polyglot environments where managing these features per-service is unsustainable.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.