Challenge 1: Explain Why Hardcoding an IP Fails — Possible Solution
====================================================================

A real microservices deployment runs a service like order-service as
MULTIPLE instances that change constantly — scaling up under load,
scaling down to save resources, restarting after a crash, or being
replaced entirely during a deployment. A hardcoded IP address points
at exactly ONE specific instance, frozen at whatever address it
happened to have at the moment the code was written.

This breaks in several concrete ways: if that specific instance
restarts or is replaced (a routine, expected event in this kind of
deployment), it may come back with a DIFFERENT IP address entirely,
and the hardcoded client has no way to find it — every call now fails
against an address that no longer serves anything. If the service
scales UP to multiple instances to handle more load, a hardcoded
single IP means every client call still goes to just that ONE
instance, missing out entirely on the extra capacity the other new
instances were meant to provide.

Service discovery solves this by giving the client a way to look up
CURRENT healthy instances at connection time (via DNS or a registry),
rather than baking in a single address that's only valid until the
next routine infrastructure change makes it stale.