System Design Examples
After a deep dive into the details of the Service Discovery pattern, it's time to zoom out and consider the bigger picture. How does this pattern apply in real-world scenarios? What are some examples of systems that use Service Discovery to coordinate their services? Let's take a look.
Use Cases
Let's first discuss where and when you might want to use the Service Discovery pattern. In general, this pattern is best suited to large, distributed systems where services need to communicate with each other but the locations of those services are subject to change.
Microservices Architectures
One prime example is a system designed around microservices. In a microservices architecture, the system is divided into small, independent services that each perform a specific function. These services need to communicate with each other to achieve the system's overall functionality.
Without Service Discovery, managing the connections between these services can become a nightmare, particularly as the system scales. With Service Discovery, services can dynamically discover and communicate with each other, significantly reducing the complexity of managing these inter-service connections.
Cloud-based Systems
Another common use case is in cloud-based systems. In the cloud, services can be dynamically allocated to different servers or locations based on demand, cost, and other factors. This can make it difficult for services to find each other without some form of Service Discovery.
With Service Discovery, services can register their new location with the Service Registry whenever they move. This makes it easy for other services to find them, regardless of where they are currently located.
System Design Examples
To illustrate these concepts, let's take a look at a couple of system design examples that make use of the Service Discovery pattern.
Example 1: E-commerce System
Consider an e-commerce system composed of multiple services: a User Service for handling user data, an Inventory Service for managing product inventory, a Shopping Cart Service for managing user shopping carts, and an Order Service for processing orders.
Without Service Discovery, each of these services would need to know the locations of the other services they interact with. If the Inventory Service moves to a new server, the User Service and Shopping Cart Service would need to update their connections accordingly.
With Service Discovery, however, the Inventory Service simply registers its new location with the Service Registry. The User Service and Shopping Cart Service can then query the Service Registry to find the Inventory Service's new location. This makes the system much more flexible and resilient to change.
Example 2: Streaming Platform
Another example could be a streaming platform where there are multiple services for managing user profiles, handling video streaming, processing payments, and recommending content based on user behavior.
In this scenario, the streaming service might need to be highly scalable to handle peak viewing times. This could involve dynamically adding or removing instances of the streaming service based on demand. Without Service Discovery, this could lead to broken connections as services try to communicate with instances that no longer exist.
With Service Discovery, the streaming service instances can register and deregister with the Service Registry as they are added and removed. Other services can then always find a valid instance of the streaming service by querying the Service Registry.
Real-World Usage
Service discovery is used in almost every large-scale microservice system in one form or another. Here are a few real-world examples and case studies:
-
Netflix: Netflix is often cited as a pioneer in microservices. Netflix's service discovery system is Eureka. In Netflix’s architecture, hundreds of services register with Eureka, and Netflix’s various applications query Eureka to find service instances. This allows Netflix to scale services up/down and move them across data centers without clients needing to know the details. Eureka has proven to handle the scale of Netflix streaming services.
-
Kubernetes: Arguably the most widespread use of service discovery today comes built into Kubernetes. Kubernetes has a concept of a Service (a stable virtual IP and DNS name for a set of pods). When new pods come up or old ones die, Kubernetes updates its internal endpoints list, and through kube-proxy or other mechanisms, ensures that traffic to the Service is load-balanced to current pods. For discovery, Kubernetes automatically configures DNS entries so that if Service X exists in the cluster, any pod can simply lookup
http://service-x(or a full DNS name) and get to it. Under the hood, Kubernetes maintains an etcd-based registry of pods and services and a cluster DNS service (CoreDNS) that answers queries based on the current registry data. So, any app running in Kubernetes is effectively using a server-side discovery pattern via DNS and the cluster’s network proxies. -
Airbnb (SmartStack): Before Kubernetes became popular, Airbnb developed a system called SmartStack for service discovery in their microservices architecture. SmartStack used HAProxy (a software load balancer) on every host and a distributed coordination service (ZooKeeper) as the registry. Each service on a host would register via a local agent, and the local HAProxy would update its configuration to route to services. This effectively gave every application a local load balancer for other services. They discovered that manually keeping track of service pools was untenable and built SmartStack to automate it.
-
Consul in Production: HashiCorp Consul is used by many companies for service discovery (and configuration). It provides DNS-based discovery as well as an HTTP API. Companies like Stripe and PagerDuty have used Consul to coordinate service discovery in their infrastructures. Consul’s ability to work across multiple data centers and provide DNS-based discovery makes it a popular choice in enterprise environments where Kubernetes might not be the orchestrator, or where a more platform-agnostic solution is needed.
-
Service Mesh Examples: Large tech companies like Google and Lyft have gravitated toward service meshes. Lyft’s Envoy was initially built to solve service discovery, routing, and observability at Lyft. Instead of each app doing discovery, Envoy sidecars receive updates from a central control plane about where every service is. So, when Service A calls Service B, it actually calls Envoy locally, and Envoy knows all the instances of B and can route intelligently. This decouples discovery logic completely from the application code and puts it into infrastructure.
In summary, the Service Discovery pattern is a powerful tool for managing service coordination in distributed systems. It allows services to dynamically discover and communicate with each other, reducing the complexity of managing connections and making the system more flexible and scalable. However, like any tool, it's important to understand its trade-offs and use it wisely.
🤖 Don't fully get this? Learn it with Claude
Stuck on System Design Examples? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **System Design Examples** (System Design) and want to truly understand it. Explain System Design Examples from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **System Design Examples** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **System Design Examples** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **System Design Examples** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.