Spring Cloud discovery: a service name locates an instance, not a trusted peer

Keep the trust boundary at the server

A receipt API may discover several stock-ledger instances under one service ID. That ID is routing input. It does not prove that an HTTP response came from a trusted deployment, and it does not grant a caller permission to reserve stock. Use transport identity where required, validate bearer claims at the receiving service, and scope the SQL predicate to the authenticated tenant. The tenant read boundary remains in force after routing.

Plan for stale membership

An instance may disappear between selection and connection. Bound connect and read timeouts, record the selected instance in low-cardinality diagnostics, then decide whether a retry is safe for that operation. Health reports and discovery registration can lag actual readiness. Readiness controls admission only for the infrastructure that observes it.

Boundary sketch

GET /api/receipts/RC-47 HTTP/1.1
Host: stock-ledger.internal
Authorization: Bearer <verified-service-token>

Cost and verification

Discovery adds a lookup or cached-membership layer. Stale membership turns some calls into connection failures; retries add latency and can multiply mutations. This sketch is not executed by the current Spring source kit; verify it against the chosen dependencies and deployment.

Common Mistakes

• Do not equate a discovered hostname with a verified caller.
• Do not move tenant authorization solely into a gateway.
• Do not retry a command because the selected instance disappeared after receiving it.

Read next

Spring Cloud client retries: distinguish a safe read from an uncertain write, Spring method authorization: reject a cross-tenant read, Spring Boot liveness versus readiness: do not restart on every dependency outage, Spring Security filter chain: authentication, CSRF and request order.