Service discovery.
Nobody memorises the taco truck’s corner — you check where it parked this morning.
There is a taco truck that moves every week, and nobody who loves it writes the corner down — they check its feed in the morning. Now picture the opposite habit: a fleet of services with each other’s addresses hard-coded, on a cloud platform that replaces machines whenever it pleases. The orders service is faithfully dialling an IP that stopped being the payments service at three in the morning.
Service discovery is the feed. Every instance announces itself on startup (name, address, port) to a registry that keeps checking pulses. Callers ask by name, “where is payments right now?”, and get an address that was alive seconds ago, not one that was true when a config file was last edited.
- It says here… 10.0.0.7.1
The config file was right the day somebody wrote it; the platform has replaced that machine twice since.
- Payments, just landed at 10.0.4.2.2
Registering is the instance’s own first act — no human updates a spreadsheet on its behalf.
- 3
Dee keeps taking pulses, so an entry that stops answering leaves the book before it can be handed out.
- Payments, please.4
Callers hold names, not numbers — a deploy or a reschedule never invalidates what the caller knows.
- Alive as of two seconds ago.5
The answer is closer to “they picked up the phone just now” than to a line in a printed phone book.
- 6
The book rewrites itself all day as instances come and go; truth lives in one place instead of a hundred config files.
Built for machines that do not sit still
Autoscaling, rolling deploys, crash replacements: a modern platform reissues servers by the hour, so any written-down address is a guess about the past. The registry flips the bookkeeping. Instead of every caller tracking every callee, each instance maintains exactly one fact, its own entry kept fresh by heartbeat, and the health checks turn the directory into a list of who will actually answer rather than who once existed.
Who does the looking up
Two arrangements are common. In client-side discovery the caller queries the registry itself and picks a healthy instance — flexible, but every service carries lookup logic. In server-side discovery the caller hits a stable name and a proxy consults the registry behind it. Kubernetes takes the second route: “payments” is simply a name that always resolves to whichever healthy pods back it today, and callers never touch a raw instance address at all.