0Pricing
WebSockets & Real-Time Systems with Spring · Lesson

Sticky Sessions and WebSocket Routing

Configure load balancers to route stateful WebSocket connections correctly using sticky sessions, and learn when a shared broker removes that need.

Sticky Sessions and WebSocket Routing is a free WebSockets & Real-Time Systems with Spring lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the WebSockets & Real-Time Systems with Spring learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

WebSockets Are Long-Lived

Unlike a stateless HTTP request, a WebSocket is a persistent connection pinned to one server instance for its entire life. This breaks the assumption load balancers make about HTTP.

The Routing Problem

If the in-memory simple broker holds a user's subscriptions on instance A, a message that lands on instance B has nowhere to deliver. The connection state lives only where the socket terminated.

Sticky Sessions (Session Affinity)

Sticky sessions make the load balancer always route a given client to the same backend instance. This keeps the socket and its server-side state co-located.

Affinity by Cookie

Cloud load balancers commonly implement affinity with a cookie they set on the first response and read on later requests.

# AWS ALB target group attribute
stickiness.enabled = true
stickiness.type = lb_cookie
stickiness.lb_cookie.duration_seconds = 86400

Forwarding the Upgrade

The load balancer must support and forward the HTTP Upgrade handshake. Most modern L7 balancers (ALB, GCP HTTPS LB, Nginx) do, but it must be enabled.

# Nginx
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Idle Timeouts Bite WebSockets

Load balancers close connections idle beyond a timeout (ALB default 60s). A mostly-quiet WebSocket gets dropped unless you send heartbeats or raise the idle timeout.

idle_timeout.timeout_seconds = 300

Health Checks and Draining

During a deploy, instances are removed. Enable connection draining so in-flight WebSockets finish (or clients reconnect) instead of being cut abruptly.

The Better Answer: Shared Broker

Sticky sessions are a workaround. A cleaner design uses a shared external broker (the STOMP relay): any instance can deliver to any subscriber, so affinity is no longer required for routing.

Combining Both

Even with a shared broker, sticky sessions can still help by keeping a client on one instance to avoid mid-stream reconnects. Use them as an optimization, not a correctness crutch.

Kubernetes Ingress Notes

On Kubernetes, the ingress controller needs WebSocket support and affinity annotations. Nginx ingress, for example, uses cookie-based affinity.

nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/proxy-read-timeout: "300"

Scaling Out Safely

To add capacity, scale instances behind the balancer and rely on the shared broker for fan-out. Keep sessions evenly spread and use draining on scale-down.

Quick Check

Test your routing knowledge.

Recap

You routed WebSockets correctly:

  • WebSockets are long-lived and pinned to one instance
  • Sticky sessions (cookie affinity) keep a client on its instance
  • The balancer must forward the Upgrade header and tolerate idle WebSockets
  • Use connection draining on deploys
  • A shared broker removes the routing need; affinity then becomes an optimization

Frequently asked questions

Is the “Sticky Sessions and WebSocket Routing” lesson free?

Yes — the full text of “Sticky Sessions and WebSocket Routing” is free to read here on the web, and the WebSockets & Real-Time Systems with Spring course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the WebSockets & Real-Time Systems with Spring course, upgrade to CoddyKit PRO.

What will I learn in “Sticky Sessions and WebSocket Routing”?

Configure load balancers to route stateful WebSocket connections correctly using sticky sessions, and learn when a shared broker removes that need. You practise WebSockets & Real-Time Systems with Spring with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start WebSockets & Real-Time Systems with Spring?

No prior experience is required. WebSockets & Real-Time Systems with Spring on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Sticky Sessions and WebSocket Routing” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this WebSockets & Real-Time Systems with Spring lesson?

Yes. Every WebSockets & Real-Time Systems with Spring lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. WebSockets in Microservice Architectures
  2. Cloud Deployment Strategies (AWS/GCP)
  3. Load Balancing and High Availability
  4. Sticky Sessions and WebSocket Routing
← Back to WebSockets & Real-Time Systems with Spring