Microservices vs. Monolith: Architecture Patterns and Trade-offs

Service Discovery

In a monolith, one module reaching another is a function call resolved at compile time. In a system of independently deployed, independently scaled services — where instances of a given service can come and go (autoscaling, rolling deploys, crashes and restarts) and their network addresses aren't fixed — a caller needs a way to find a current address for "the Orders service" without hardcoding an IP that might not exist five minutes from now.

• Client-side discovery — the calling service asks a registry (a dedicated service-discovery tool, or DNS) for a current list of healthy instances and picks one itself, often load-balancing across them client-side.
• Server-side discovery — the caller just calls a stable address (a load balancer or an API gateway, below), which itself looks up and routes to a current healthy instance — the caller never needs to know discovery is happening at all.

Most systems built on a container orchestrator (Kubernetes, for instance) get this largely for free — a Kubernetes Service provides a stable DNS name and load-balances to whichever pod instances are currently healthy, so application code just calls a fixed hostname and the platform handles the fact that the underlying instances are constantly changing underneath it.