Microservices Load Balancing Interview Questions and Answers

Running multiple instances of a service is how microservices scale and stay available — and load balancing is what makes those instances useful by spreading traffic across them. Interviewers use this topic to check that you understand the algorithms, where balancing happens, and how it cooperates with health checks and discovery to avoid dead instances. This page covers the load balancing questions asked in microservices interviews and the practical follow-ups.

What is load balancing and why does it matter here?

Distributing requests across multiple instances of a service so no instance is overwhelmed, throughput scales horizontally, and the failure of one instance does not take the service down. It is the mechanism that turns "we run three copies" into real availability and capacity.

Load balancing only works well when services are stateless, because any instance must be able to serve any request. That is why "make it stateless and put session state in Redis" is a recurring theme — statelessness is the precondition for free, even distribution.

What are the common load-balancing algorithms?

Round robin (rotate evenly), least connections (route to the least busy instance), weighted (bias toward more capable instances), and hash-based (route by a key such as client IP for stickiness). Each fits a different traffic shape.

Round robin is simple and fine when requests are uniform. When request durations vary widely, least connections avoids piling long requests on one instance. Weighted helps during rollouts or with heterogeneous hardware. Hash-based gives affinity when you genuinely need the same client on the same instance.

Interview note: Follow-up: "round robin sends equal traffic but one instance is overloaded — why?" Because requests are not equal cost. A few expensive requests can saturate an instance that round robin still feeds. Least connections or latency-aware balancing fixes it.

Client-side vs server-side load balancing — what is the difference?

Client-side: the caller knows all instances (via discovery) and picks one itself, avoiding an extra hop. Server-side: a dedicated balancer or gateway sits in the path and distributes requests, keeping clients simple.

Client-side (Spring Cloud LoadBalancer, gRPC client-side LB) removes a network hop and gives fine control, but every client must implement the logic. Server-side (a hardware/cloud LB, a Kubernetes Service, a gateway) centralizes it and works across languages, at the cost of a hop and a component to run. On Kubernetes, server-side is the default.

Layer 4 vs Layer 7 load balancing — when do you use each?

L4 balances on IP and port at the transport layer — extremely fast but content-blind. L7 balances at the application layer, so it can route by path, header, or cookie and terminate TLS, at a modest performance cost. Use L4 for raw throughput; use L7 when you need content-based routing.

An API gateway is essentially an L7 load balancer with extra responsibilities (auth, rate limiting). Making that connection shows you see how the edge components relate rather than treating each as isolated.

Why are health checks essential to load balancing?

A balancer must only send traffic to instances that can actually serve it, so it continuously health-checks each instance and removes any that fail from the rotation. Balancing without health checks happily routes requests into a dead or overloaded instance.

The refinement is readiness vs liveness: a starting instance may be alive but not ready to serve, and the balancer should hold traffic until readiness passes. This is exactly how a Kubernetes Service uses readiness probes to manage its endpoint list.

# Kubernetes readiness probe — a failing probe removes the pod from Service endpoints
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

That single probe is the link between health checking and load balancing — fail it, and traffic stops flowing to the pod automatically.

What are sticky sessions and why are they discouraged?

Sticky sessions pin a client to one instance so in-memory session state stays reachable. They are discouraged because they defeat even distribution and resilience — if the pinned instance dies, the session is lost, and scaling becomes lopsided.

The recommended fix is to make services stateless and externalize session state to a shared store (Redis) or use stateless tokens (JWT). Then any instance can serve any request and the balancer is free to distribute optimally.

Interview note: Trap: "just enable sticky sessions to fix the login bug." That treats the symptom. The real fix is externalizing session state so stickiness is unnecessary.

How does load balancing interact with service discovery?

Discovery supplies the current list of healthy instances; load balancing chooses among them. They are two halves of one flow — discovery answers "which instances exist and are healthy?" and balancing answers "which one gets this request?"

In client-side setups both happen in the caller; in server-side setups both happen in the gateway or Kubernetes Service. Either way, the balancer's instance list is only as good as the health signals feeding it.

How is traffic balanced across instances in Kubernetes?

A Service load-balances across its healthy backing pods through kube-proxy, and its endpoint set is kept current by readiness probes. External traffic enters through an Ingress or a cloud load balancer that distributes into the cluster. Balancing is infrastructure you configure, not code you write.

How does load balancing support zero-downtime deployments?

During a rolling update, new instances only receive traffic once they pass readiness checks, and old instances are drained before termination — so the balancer always has healthy targets and users see no downtime. Balancing plus health checks plus graceful shutdown is what makes rolling deploys safe.

What interviewers really test

Load balancing questions verify that you understand horizontal scaling as a system: stateless services, health-checked instances, an algorithm suited to your traffic, and the cooperation between discovery and balancing. The best answers connect the pieces — why statelessness matters, why health checks gate traffic, why sticky sessions are a smell — rather than listing algorithms. Be ready to reason about uneven load, not just even load.

Load balancing sits between discovery and resilience, so pair this with the service discovery questions and the resilience patterns question set for the full availability picture. Solidify the fundamentals with the microservices learning path, and rehearse the algorithm and stickiness trade-offs in a mock interview.