Service Discovery Flow: Mermaid Flowchart Diagram

Service Discovery Flow flowchart diagram

About Source

Service discovery is the mechanism by which services in a distributed system locate each other's network addresses dynamically — without hardcoded hostnames — so that deployments, scaling events, and failures don't require configuration changes.

What the diagram shows

This flowchart covers the client-side service discovery pattern, which is the most common approach in Kubernetes and Consul-based environments:

1. Service registers: when a new instance of a service starts, it registers its IP address and port with the Service Registry (e.g., Consul, Eureka, or Kubernetes Service objects). 2. Health check: the registry periodically health-checks registered instances and removes those that fail. 3. Caller queries registry: when Service A needs to call Service B, it queries the registry for healthy instances of Service B. 4. Load balance: the caller (or a sidecar proxy) selects one instance using a load-balancing strategy — round-robin, least connections, or weighted. 5. Call selected instance: the request is sent directly to the selected instance's address. 6. Deregister on shutdown: graceful shutdown triggers deregistration, removing the instance from the pool before connections drain.

Why this matters

Without service discovery, scaling a service requires updating every caller's configuration. With it, new instances self-register and immediately receive traffic — and failed instances are automatically removed from the pool, reducing the need for manual intervention.

Service discovery is a prerequisite for the patterns shown in Microservice Request Chain and API Gateway Request Flow. When an instance becomes unhealthy and calls start failing, the Circuit Breaker Pattern prevents cascading failures while discovery catches up.

Frequently asked questions

Service discovery is the mechanism by which services in a distributed system locate each other's network addresses dynamically — without hardcoded hostnames or IPs — so that scaling events, deployments, and failures don't require configuration changes across all callers. A service registry acts as the central directory, with services self-registering on startup and deregistering on shutdown.

When a new service instance starts, it registers its IP address and port with the registry (e.g., Consul, Eureka, or a Kubernetes Service). The registry periodically health-checks all registered instances and removes unhealthy ones. When a caller needs to reach a service, it queries the registry for healthy instances and selects one using a load-balancing strategy — round-robin, least connections, or weighted — then sends the request directly to that instance's address.

Use service discovery in any system where services scale horizontally or where instances are replaced frequently — container orchestration platforms like Kubernetes, auto-scaling groups in cloud environments, or any microservices deployment where hardcoding service addresses is impractical. In static environments with a small number of fixed services, a simple DNS entry or load balancer may suffice.

In client-side discovery, the calling service queries the registry and performs load balancing itself before making the call — giving the client full control over instance selection. In server-side discovery, the client sends the request to a load balancer or proxy (such as an API gateway or service mesh sidecar) which queries the registry and forwards to an instance transparently. Client-side discovery is simpler but couples the client to the registry; server-side discovery centralizes routing logic but adds an infrastructure hop.

mermaid

flowchart TD
    A([Service instance starts]) --> B[Register IP and port with Service Registry]
    B --> C[Registry stores instance metadata]
    C --> D{Health check passes?}
    D -- Fails --> E[Registry marks instance unhealthy]
    E --> F[Remove from available pool]
    D -- Passes --> G[Instance remains in healthy pool]

    H([Caller needs to reach Service B]) --> I[Query Service Registry for Service B]
    I --> J{Healthy instances found?}
    J -- None --> K[Return service unavailable error]
    J -- Found --> L[Apply load balancing strategy]
    L --> M[Select target instance]
    M --> N[Send request to instance address]
    N --> O{Request succeeded?}
    O -- Yes --> P([Return response to caller])
    O -- No --> Q[Mark instance suspect]
    Q --> D

    R([Service instance shuts down]) --> S[Deregister from Service Registry]
    S --> F