Which three points require evidence before adoption?

Service name, Endpoint set, Stale window.

Standalone conceptMechanismChapter II · Communication · Building block 18 of 23

Service Discovery

Service discovery resolves a stable service name at runtime to a set of reachable endpoints.

By Michael Meierhoff · Meierhoff Systems

Service nameRemains stable while instances change.
Endpoint setContains currently known candidates and health state.
Stale windowBounds selection of already failed targets.

Context

Why this is important

Discovery reports known endpoints; actual reachability and successful business response remain responsibilities of client, load balancer, and application.

The distributed extension in the shop scenario is hypothetical; the current shop remains a modular monolith with seven modules and one shared database.

Shop example · Mapping

Service Discovery: decision boundaries

The current shop has seven modules in one process. Hypothetically, Shipping runs on three changing instances behind the logical name shipping. The platform publishes endpoint changes and removes a faulty instance according to its health rule. The team stops one instance during traffic and measures time to removal, failed attempts from caches, and behavior during discovery outage. Only a bounded stale period and successful re-resolution support the guarantee.

This is how you read the picture

Service name Logical address
Endpoint set Versioned update
Stale window TTL plus deregistration

Service Discovery: decision boundaries
Comparison	Aspect	Sound use	Limit
DNS-based	Widely supported and simple	TTL bounds freshness	Client cache may retain old targets
Registry/API	Fast endpoint updates	Watch or query	Registry outage needs cache path
Platform service	Discovery plus load balancing	Platform manages endpoints	Platform semantics determine health and routing

The matrix connects benefit, ownership, and boundary.

Benefits & limitations

Helps if:

TTL bounds freshness
Watch or query
Platform manages endpoints

Boundaries

Client cache may retain old targets
Registry outage needs cache path
Platform semantics determine health and routing

In practice

Start and stop shipping instances during active order queries. Check how quickly discovery publishes the current endpoint set.
Make a registered endpoint stop responding. Verify that health checking or client strategy does not keep selecting it as healthy.
Compare DNS-based with API-based discovery by cache time, failure signal, and platform dependency. Record a measurable freshness guarantee.

Read the detailed explanation

Instances register or are observed by the platform. DNS, a registry, or an endpoint API supplies candidates from which a client or proxy selects a target.

TTL, health-check interval, and deregistration time determine how long a failed target may still be selected. Caches need defined behavior when discovery itself fails.

Load Balancing selects among discovered targets. Service Mesh can consume discovery and handle routing.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What is the core task of Service Discovery?
View the solution with justification
Service discovery resolves a stable service name at runtime to a set of reachable endpoints.
ApplyingTransferred to a new situation
Which assumption is hypothetical in the shop?
View the solution with justification
Hypothetically, Shipping runs on three changing instances behind the logical name shipping. The platform publishes endpoint changes and removes a faulty instance according to its health rule.
EvaluateWeighing an alternative
Which three points require evidence before adoption?
View the solution with justification
Service name, Endpoint set, Stale window.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Communication & APIs: service-mesh.

23 Building blocks

Continue withservice-mesh