Real-world examples of service discovery in microservices architectures

Why real examples of service discovery in microservices matter

You can read a dozen theory articles and still have no idea how service discovery actually looks in code, configs, or production incidents. That’s why the best examples of service discovery in microservices come from real platforms and real design decisions, not abstract patterns on a whiteboard.

Service discovery is the glue that lets one service find another without hardcoding IPs or hostnames. As you scale from a few containers to hundreds of services, that glue either holds or your system spends its life in a partial outage.

Below, we’ll unpack several examples of examples of service discovery in microservices, from Kubernetes DNS to Netflix’s client libraries to AWS Cloud Map and HashiCorp Consul. The goal is simple: give you patterns you can actually copy, not just vocabulary.

Kubernetes DNS: the most common example of service discovery in microservices

If you’re running containers in 2024, odds are good you’re running Kubernetes. And Kubernetes gives one of the cleanest examples of service discovery in microservices: DNS-based discovery backed by the Kubernetes API server.

Here’s how it works in practice:

• Each Kubernetes Service object gets a stable DNS name like payments.default.svc.cluster.local.
• Pods that implement the payments API register themselves with that Service via labels and selectors.
• The kube-dns or CoreDNS add-on exposes the Service as a virtual IP (ClusterIP), and kube-proxy keeps the routing rules updated.
• Any other microservice just calls http://payments (or the full DNS name) and lets Kubernetes handle the rest.

This is a textbook example of server-side discovery: clients don’t know or care which pod they hit. They only know the logical name. In many organizations, this is the first example of service discovery in microservices that developers actually touch.

Trends worth noting in 2024–2025:

• More teams are standardizing on ClusterIP + DNS even for internal gRPC traffic, relying on Kubernetes for naming and basic load balancing.
• Multi-cluster setups increasingly use tools like Kubernetes Gateway API and service mesh multi-cluster features to extend the same DNS-style discovery across clusters.

For a deeper understanding of distributed naming and consistency (which underpins systems like Kubernetes), the classic Paxos and consensus literature from places like MIT is still highly relevant.

Netflix OSS: client-side discovery as a classic example

Before Kubernetes became the default, Netflix popularized another pattern: client-side service discovery. Their stack (Eureka, Ribbon, Hystrix) is still one of the best examples of service discovery in microservices where the client owns the routing logic.

In the Netflix model:

• Each service instance registers itself with Eureka, a dedicated service registry.
• Clients query Eureka to get a list of healthy instances for, say, the catalog-service.
• The client library (Ribbon back in the day, now often replaced by modern HTTP clients) picks an instance using a load-balancing strategy.

This gives a different flavor of discovery compared to Kubernetes DNS:

• The registry is explicit and visible.
• The client is smart: it can apply custom routing, traffic shaping, and failover logic.
• The load balancer is in the application process, not at the node or cluster level.

Modern Java stacks like Spring Cloud still use this style, often with Netflix Eureka or alternatives like Consul or Zookeeper. If you want a concrete example of how client-side discovery looks in code, Spring Cloud’s @LoadBalanced RestTemplate and WebClient integrations are a good starting point.

HashiCorp Consul: multi-platform, multi-datacenter discovery

HashiCorp Consul is another widely used example of service discovery in microservices, especially in hybrid or multi-cloud environments.

Typical Consul-based setups look like this:

• Each service instance runs a Consul agent, which registers the service with the Consul cluster.
• Health checks (HTTP, TCP, or script-based) run from the agent to ensure the instance is actually alive.
• Other services query Consul via:
  • DNS interface (e.g., payments.service.consul), or
  • HTTP API for richer metadata and filtering.

Some reasons Consul keeps showing up in real examples:

• It works across VMs, bare metal, and containers, not just Kubernetes.
• It supports key/value config, so teams often combine service discovery with config management.
• It integrates well with service meshes (Consul Connect), which we’ll get to next.

Consul is a good example of service discovery in microservices when your environment is messy: multiple clusters, legacy hosts, different runtimes, or a gradual migration from monoliths to microservices.

Service mesh and sidecars: modern examples include Istio and Linkerd

Service meshes like Istio, Linkerd, and Consul Connect give another modern example of examples of service discovery in microservices: the sidecar proxy model.

In a mesh:

• Each microservice pod runs a sidecar proxy (Envoy for Istio, Linkerd’s own proxy, etc.).
• The mesh control plane maintains a registry of services, instances, and policies.
• When Service A calls Service B, it actually talks to its local sidecar, which then routes to B’s sidecar based on the mesh’s service discovery data.

The sidecar pattern changes who is responsible for discovery:

• Application code talks to a logical name (e.g., http://orders), often still via Kubernetes DNS.
• The sidecar handles routing, retries, timeouts, mTLS, and observability.
• The control plane (Istio Pilot, Linkerd control, Consul Connect) keeps the service registry up to date.

This is one of the best examples of service discovery in microservices when you need advanced traffic control: canary releases, regional failover, or detailed telemetry without rewriting every service.

For more background on distributed systems reliability and patterns that underlie meshes, the materials from places like Carnegie Mellon’s SEI offer useful conceptual grounding.

AWS Cloud Map and App Mesh: cloud-native examples for serverless and containers

If you’re all-in on AWS, their stack offers several real examples of service discovery in microservices that integrate tightly with managed services.

Two common patterns:

1. AWS Cloud Map for naming and discovery

• Services register with AWS Cloud Map using logical names.
• Cloud Map stores metadata like IPs, ports, and health status.
• Callers discover services via AWS SDKs, DNS, or integrations with other AWS components.

This is especially useful when mixing ECS, Lambda, and EC2 in the same architecture. For example, a Lambda function can discover an ECS-based payments service via Cloud Map without caring where it runs.

2. AWS App Mesh with Envoy sidecars

• Similar to Istio, App Mesh uses Envoy sidecars for traffic management.
• It integrates with EKS (Kubernetes), ECS, and EC2.
• Service discovery is handled by mapping logical names to endpoints via App Mesh and Cloud Map.

These are concrete examples of examples of service discovery in microservices where the cloud provider manages most of the heavy lifting. You trade some portability for tighter integration with load balancers, IAM, and logging.

AWS’s architecture guidance often echoes general distributed systems principles you’ll also find in academic and public-sector work on resilient systems, such as resources from NIST on secure system design.

API gateways as a discovery layer: practical gateway examples

API gateways are often discussed as if they’re just about rate limiting and authentication. In reality, they’re also a very practical example of service discovery in microservices, especially for north-south traffic (from outside into your system).

In a typical gateway setup:

• Clients call a single public endpoint, like https://api.example.com.
• The API gateway (Kong, NGINX, Apigee, AWS API Gateway, etc.) routes each request to the right internal service.
• Behind the scenes, the gateway uses:
  • Static upstream configs, or
  • Dynamic service discovery via Consul, Kubernetes, or cloud-native registries.

Real examples include:

• A gateway configured to route /orders/** to the orders-service via Kubernetes DNS.
• A gateway integrated with Consul, so new instances are picked up automatically without redeploying the gateway.

While the gateway itself isn’t the registry, it becomes the public face of your discovery strategy. For many teams, the first production incident involving service discovery is actually an API gateway misconfiguration.

Concrete, end-to-end examples of examples of service discovery in microservices

To make this less abstract, let’s walk through several end-to-end scenarios you might actually build.

Example of discovery in a simple Kubernetes-based e‑commerce system

Imagine an e‑commerce platform with services like catalog, cart, orders, and payments, all running on Kubernetes.

• Each service has a Kubernetes Service object: catalog, cart, orders, payments.
• The frontend calls http://catalog to list items, http://cart to manage the cart, and http://orders to place orders.
• The orders service calls http://payments to charge the customer.

Here, Kubernetes DNS and Services are the primary example of service discovery in microservices. No one is hardcoding pod IPs, and when you scale payments from 3 to 10 pods, no application code changes.

Example of hybrid discovery with Consul and legacy VMs

Now picture a financial services company with:

• New microservices on Kubernetes.
• Legacy services running on VMs.
• A shared Consul cluster.

The pattern looks like this:

• Kubernetes services are exposed via Consul using an integration that syncs Kubernetes Service objects into Consul.
• Legacy VM-based services register directly with Consul agents.
• All services discover each other via *.service.consul DNS names.

This gives a real example of examples of service discovery in microservices that span both modern and legacy environments without forcing a big-bang migration.

Example of client-side discovery in a Spring Cloud system

A Java shop using Spring Boot and Spring Cloud Netflix might do the following:

• Spin up a Eureka server as the registry.
• Each microservice registers itself with Eureka on startup.
• Services use a @LoadBalanced RestTemplate to call other services by logical name, e.g., http://billing-service/invoices.

Here, the Spring client libraries hide the details, but under the hood they are a textbook example of client-side service discovery in microservices.

Example of serverless discovery with AWS Lambda and ECS

Consider a data processing pipeline on AWS:

• Ingest microservices run on ECS.
• Processing steps run as Lambda functions.
• A shared AWS Cloud Map namespace holds service names.

The flow:

• ECS tasks register ingest-service and transform-service with Cloud Map.
• Lambda functions use the AWS SDK to discover these services at runtime.
• When ECS tasks scale out, the new endpoints automatically appear in Cloud Map.

This is one of the best examples of service discovery in microservices where serverless and container workloads need to talk to each other without fixed endpoints.

Example of service mesh discovery with zero code changes

A platform team decides to add Istio to an existing Kubernetes cluster:

• They inject Envoy sidecars into each deployment.
• They define VirtualServices and DestinationRules mapping logical service names to subsets (e.g., v1, v2).
• Application code still calls http://orders, unaware of the mesh.

Now the team can:

• Send 10% of traffic to orders v2 for canary testing.
• Fail over traffic between clusters if one region degrades.

Here, the mesh control plane and sidecars provide an advanced example of service discovery in microservices while keeping application code almost blissfully ignorant.

How to choose between these examples of service discovery in microservices

Looking across these patterns, some practical guidelines emerge:

• Use Kubernetes DNS and Services when you’re mostly in Kubernetes and your discovery needs are straightforward.
• Use client-side discovery (Eureka, Consul client, custom libraries) when you want application-level control over routing and load balancing.
• Use Consul or similar registries when you have a mix of environments (VMs, bare metal, multiple clusters) and need a shared view of services.
• Use a service mesh when you care about traffic shaping, observability, and security policies as much as basic discovery.
• Use cloud-native registries like AWS Cloud Map when you’re tightly coupled to that cloud and want managed integrations with other services.

Most mature organizations end up with a combination of these. For example, Kubernetes DNS for internal calls, a mesh for advanced control, and an API gateway for external traffic.

If you’re interested in the broader reliability and observability story around these choices, the general engineering guidance from institutions like Harvard’s CS courses and NIST on secure, observable systems can provide useful context beyond vendor docs.

FAQ: common questions about examples of service discovery in microservices

What are some real examples of service discovery in microservices?

Real examples include:

• Kubernetes Services and DNS names resolving to pods.
• Netflix Eureka with client libraries doing client-side load balancing.
• HashiCorp Consul acting as a registry across VMs and containers.
• Service meshes like Istio and Linkerd using sidecar proxies and a control plane.
• AWS Cloud Map combined with ECS, EKS, and Lambda for cross-service naming.
• API gateways routing from a single public endpoint to many internal services using dynamic discovery.

Which example of service discovery should I start with for a new project?

If you’re starting on Kubernetes, the simplest path is to rely on Kubernetes Services and DNS first. That gives a clean, built-in example of service discovery in microservices without extra moving parts. As your needs grow, you can layer in a service mesh or external registry without throwing away the basic pattern.

Can I mix multiple examples of service discovery in the same architecture?

Yes, and most real systems do. A common setup is:

• Kubernetes DNS for in-cluster traffic.
• A service mesh for advanced routing and observability.
• An API gateway for external calls.
• A registry like Consul or Cloud Map for cross-environment discovery.

The key is to be intentional about who owns the source of truth for each traffic path so you don’t end up debugging three conflicting registries.

How do health checks relate to service discovery?

Service discovery without health checks just gives you a list of possible targets, not a list of good ones. Systems like Consul, Eureka, and service meshes integrate health checking so that only healthy instances are returned to callers. Kubernetes does something similar with readiness and liveness probes on pods.

Is DNS alone enough as an example of service discovery in microservices?

For many small to medium systems, yes. DNS-based discovery, especially when backed by something like Kubernetes Services, is a perfectly valid example of service discovery in microservices. As you grow, you might add richer metadata, traffic policies, or security constraints that push you toward a registry or mesh, but DNS is often where the story starts.