Microservices Communication

Service discovery lets services locate one another without hardcoded addresses, which is essential when instances scale up, down, or move across hosts. A registry tracks healthy instances and their network locations; services query it or rely on a load balancer to route requests. Patterns include client-side discovery, where the caller queries the registry, and server-side discovery via a router. Tools like Consul, Eureka, and Kubernetes DNS implement this so the system stays connected as the deployment topology changes.

An API gateway is a single entry point that sits in front of backend microservices, routing each incoming request to the appropriate service. It often handles cross-cutting concerns such as authentication, rate limiting, request aggregation, and response transformation, so individual services do not have to. This shields clients from the internal service topology and reduces the number of round trips. The trade-off is that the gateway can become a bottleneck or single point of failure if not designed for scale and resilience.

A circuit breaker protects a system from a failing dependency by monitoring call failures. When failures cross a threshold the breaker opens, causing further calls to fail fast or return a fallback instead of waiting on a struggling service. After a cooldown it moves to half-open, letting a few trial calls through; if they succeed it closes again. This prevents a single failure from cascading and exhausting resources across the system, improving overall resilience and recovery time.

A retry re-attempts an operation that failed due to a transient problem, like a brief network blip or a momentarily overloaded service. To avoid hammering a struggling dependency, retries should use exponential backoff with jitter, spacing attempts out and randomizing them. Retries are safest on idempotent operations, where repeating has no harmful effect. Combined with circuit breakers and sensible limits, well-tuned retries improve reliability without amplifying load during widespread outages.

A saga coordinates a business transaction that spans multiple services without a distributed lock. It breaks the work into a sequence of local transactions; if one step fails, the saga runs compensating actions to undo the previously completed steps, preserving consistency. Sagas come in two styles: choreography, where services react to each other's events, and orchestration, where a central coordinator directs the steps. They trade strict ACID guarantees for eventual consistency suited to microservice architectures.