Conceptly
← All Concepts
🧭

Service Discovery

IntegrationA mechanism for finding changing service locations by stable name

Service Discovery is the internal address book that resolves a stable service name to the live network locations of its instances at runtime. Callers send requests using just a name, without tracking concrete IPs or ports themselves.

β–ΆArchitecture Diagram

πŸ”— Relationship

Dashed line animations indicate the flow direction of data or requests

Why do you need it?

When instances scale up, get replaced, or move, callers cannot realistically track raw addresses forever. In container and cloud environments, yesterday's endpoint can disappear quickly. Designs that assume fixed addresses do not hold up well under dynamic operations. Service Discovery absorbs that instability by separating names from live locations.

Why did this approach emerge?

When servers stayed fixed for long periods, it was common to hardcode addresses in configuration. Cloud platforms and container schedulers changed that assumption by making instances far more dynamic. Once service names needed to stay stable while real endpoints kept moving, systems needed a first-class way to resolve live targets at runtime. Service Discovery became part of the operating substrate for that reason.

How does it work inside?

Services register themselves, or the platform registers them, in a discovery registry. Callers resolve a stable service name to the set of currently healthy instances. Health checks remove dead endpoints and add new ones as the system changes. The key value is that callers depend on logical names instead of memorizing concrete network locations.

What is it often confused with?

Service Discovery and API Gateway both touch the question of where traffic should go, but Service Discovery solves internal location resolution, while API Gateway organizes external entry and policy. One is an internal runtime mechanism; the other is an externally visible front door.

When should you use it?

Service Discovery is almost foundational in autoscaled services, rolling deployments, service mesh environments, and container platforms. It lets callers depend on stable service names while operators change instances underneath. But hiding addresses does not eliminate failure, so health checks and observability still matter alongside discovery.

Container environments where instances frequently start and stopMicroservice systems with dynamic internal call targetsPlatforms that need health-based target selectionSystems that must communicate by service name rather than fixed IPs