Load Balancing

Layer 4 load balancing operates at the transport layer and uses information such as TCP or UDP, IP addresses and ports. Layer 7 load balancing operates at the application layer and can inspect HTTP information such as hostnames, URL paths, headers and cookies. Layer 7 routing can direct different paths to different services, while Layer 4 routing works with lower-level connection information.

Round robin sends requests to instances sequentially. Weighted round robin assigns different proportions of traffic to instances with different capacities. Least connections chooses an instance with fewer active connections. IP hash uses a client's IP address to select an instance and can provide affinity, but may cause uneven distribution. No algorithm guarantees uniform work when requests have very different costs or when traffic is uneven.

A load balancer should avoid sending new traffic to instances that are not ready to serve requests. Active health checks periodically call a health endpoint. Passive checks observe failures in real traffic. In the Task Management API example, an endpoint such as GET /actuator/health can provide health information. A robust deployment should distinguish liveness from readiness where the platform supports those concepts, and should avoid declaring an instance healthy merely because its process exists.

A reverse proxy sits between clients and backend servers. In addition to forwarding requests, it can provide routing, TLS termination, load balancing, compression, request filtering and header manipulation. NGINX is one example. TLS termination may happen at the proxy, but whether the internal hop uses HTTP or HTTPS depends on the deployment's security requirements and trust boundaries.

Session affinity, also called sticky sessions, attempts to route requests from the same client to the same server. It can be useful for systems that retain session state locally, but it reduces routing flexibility and does not solve state loss when an instance fails. The supplied Task Management API design prefers stateless API instances with shared state, so sticky sessions are unnecessary for the intended model.

If App 1 fails while App 2 and App 3 remain healthy, the load balancer should remove App 1 from rotation and continue routing requests to the healthy instances. This improves resilience at the application tier. It does not guarantee end-to-end availability if PostgreSQL, Redis, DNS, the network or the load balancer itself is unavailable. A complete availability design examines every critical dependency.