Load Balancer Configuration for a Legacy Application
A legacy Java application runs on three servers behind a load balancer and serves 2,000 concurrent users. Session state is stored in each server's local memory. The load balancer uses cookie-based sticky sessions with a 30-minute expiry. After autoscaling added a fourth server, many users were logged out mid-session. The health check is a TCP connect to port 8080; the application returns HTTP 200 even when its database connection pool is exhausted, which has caused intermittent 502 errors. TLS terminates at the load balancer. About 8% of clients still use TLS 1.0 or 1.1, while security policy now requires TLS 1.2 or higher. The load balancer idle timeout is 60 seconds, but the application's HTTP keepalive is 300 seconds. The team must fix session stability, reduce 502s, and meet the TLS requirement without an immediate hard cutoff that would break paying customers.
1. Diagnose the logout problem and recommend the smallest configuration or architecture change that fixes it without a full rewrite.
Read the worked answer
The logout is caused by local-memory sessions combined with sticky routing that changes when capacity changes. A new server has no copy of existing sessions, and if the load balancer rebalances or the persistence cookie is not honored consistently, users are sent to a node that cannot validate their session. Source-IP persistence can also break when clients change NAT addresses.
The robust fix is to externalize sessions to a shared store such as Redis with a TTL longer than the application session timeout, then remove stickiness or make it optional. That lets any server serve any user and makes autoscaling safe. If a rewrite is not possible in the short term, enable session replication between the Java servers and keep cookie-based persistence with a consistent cookie name, path, and expiry. Ensure new instances join the replication group before receiving traffic, and enable connection draining during scale-in. The smallest durable change is the shared session store; increasing cookie expiry alone does not fix the missing session on the new node.
2. Redesign health checking and timeout settings to reduce 502 errors. Explain how your changes interact.
Read the worked answer
A TCP check only proves the port is open, not that the application can serve requests. Replace it with an HTTP health endpoint that verifies the database connection pool, for example by checking that active connections are below 90% of maximum and running a lightweight validation query. Use a 10-second interval, 3-second timeout, three unhealthy failures, and two healthy successes. That removes a node with an exhausted pool before it generates more 502s.
The 60-second load-balancer idle timeout is shorter than the application's 300-second keepalive, so the load balancer can close a connection that the application still believes is open. Set the load-balancer idle timeout above the application keepalive, or reduce the application keepalive below the load-balancer timeout, so one side does not expire first. Also size the database pool for 2,000 concurrent users, add a connection-acquisition timeout, and retry only idempotent requests. Enable connection draining so scaled-in nodes finish in-flight requests. Health checks and timeouts must be tuned together; fixing only one still leaves 502s.
3. Propose a TLS migration path that satisfies security while managing the 8% legacy clients. Include a measurable exit criterion.
Read the worked answer
Do not disable TLS 1.0/1.1 on the main listener immediately. First inventory the 8% by client type, contract value, and ability to upgrade. Set the primary listener to TLS 1.2 or higher with strong cipher suites. For legacy clients, create a separate listener or reverse-proxy endpoint on a distinct hostname that temporarily allows TLS 1.0/1.1 with compensating controls: extra logging, rate limiting, WAF inspection, and restricted access where possible. Notify affected customers with a dated migration plan and offer configuration guidance.
Measure legacy usage continuously. Exit criterion: less than 0.5% of sessions on the legacy endpoint for 30 consecutive days, with no active contractual exception, then disable it. If a customer cannot migrate by the deadline, require a signed risk acceptance with an expiry date and executive approval. This satisfies the policy direction while avoiding a hard cutoff that breaks paying customers on day one.