Service discovery concept in Microservices - System Design Guide

Problem Statement

When microservices need to communicate, hardcoding service locations causes failures if services move or scale. Without a dynamic way to find service addresses, requests fail or become slow, breaking the system's reliability and scalability.

Solution

Service discovery automatically tracks where each service instance is running and provides this information to clients. When a service wants to call another, it queries the discovery system to get the current address, ensuring requests always reach a live instance even as services scale or move.

Architecture

Service A

→Service Discovery

↓

Instance B1

This diagram shows Service A querying the Service Discovery system to find the current instances of Service B. The discovery system tracks multiple instances of Service B and provides their addresses to Service A.

Trade-offs

✓ Pros

→

Enables dynamic scaling and movement of services without manual reconfiguration.

→

Improves fault tolerance by routing requests only to healthy service instances.

→

Simplifies client logic by centralizing service location management.

✗ Cons

→

Introduces an additional component that can become a single point of failure if not highly available.

→

Adds network overhead due to service registration and lookup calls.

→

Requires careful synchronization to keep service registry up to date.

Use when your system has multiple microservices that scale independently and change locations frequently, typically at 100+ service instances or when dynamic scaling is essential.

Avoid if your system has a small number of static services with fixed addresses and low scaling needs, as the added complexity and overhead are unnecessary.

Real World Examples

Netflix

Uses Eureka for service discovery to enable dynamic scaling and failover of its streaming microservices.

Amazon

Employs service discovery in AWS ECS to allow containers to find each other dynamically as they scale.

Uber

Uses service discovery to route requests between microservices that frequently scale and move across data centers.

Alternatives

Client-side service discovery

Clients query the service registry directly and choose service instances themselves.

Use when: When clients can handle load balancing and failure detection, reducing the need for a proxy.

Server-side service discovery

A load balancer or proxy queries the service registry and routes requests on behalf of clients.

Use when: When you want to simplify clients and centralize routing logic.

DNS-based service discovery

Uses DNS records to resolve service addresses dynamically instead of a dedicated registry.

Use when: When infrastructure supports dynamic DNS updates and you want to leverage existing DNS tools.

Summary

Service discovery prevents failures caused by hardcoded or outdated service addresses in dynamic microservice environments.

It works by maintaining a registry of live service instances and providing clients with current addresses on demand.

This pattern enables scalable, resilient communication between services but adds complexity and requires careful management.