Sticky Sessions

Sticky Sessions Routing for Traffic Distributor

Sticky Sessions provides server affinity by assigning each user to one backend and keeping all later requests from that user on the same application environment.

On the first visit, a user is routed according to the configured backend weights. After the backend is selected, Traffic Distributor remembers the assignment and sends subsequent requests from the same browser to that environment until the session expires or the routing cookie is removed.

Sticky Sessions routing in Traffic Distributor
New users are distributed by backend weight, while returning users remain attached to their assigned environment.
On this page

How Sticky Sessions Works

  • A new visitor reaches Traffic Distributor.
  • The visitor is assigned to one backend according to the configured server weights.
  • The selected backend is stored in a session cookie.
  • All later requests from the same browser are routed to that backend.
  • The assignment ends when the session expires or the cookie is removed.
Sticky Sessions is useful when an application keeps session information or temporary user state locally on an application server.

Cookie-Based Affinity

Some load-balancing systems use the client IP address to maintain affinity. This method can produce uneven results because many users may share one IP address behind a corporate proxy, carrier network, or gateway.

Traffic Distributor uses session cookies instead. Each browser is treated as an individual user, which produces more accurate and balanced assignment.

Browser-specific assignment: The same person using another browser or a private browsing session can be treated as a new user and may be assigned to a different backend.

Backend Weights

New users are distributed in a way similar to Round Robin routing. The configured percentage controls how many new browser sessions are initially assigned to each backend.

50 / 50
Equal User Distribution Approximately half of new users are assigned to each application environment.
70 / 30
Weighted User Distribution More new users are assigned to the higher-priority backend.
100 / 0
Single Backend for New Users All new sessions go to one backend, while existing users can remain on their previous assignment until the cookie expires.

Once a user is assigned, later requests stay on that backend regardless of any subsequent traffic-weight change until the existing affinity cookie is no longer valid.

Traffic Distribution Examples

50% / 50%: An approximately equal number of unique browser sessions is assigned to each backend. This is suitable for comparing two application versions during A/B testing.
70% / 30%: Around seven out of ten new users are assigned to the first backend and three to the second, while returning users continue using their original backend.
Weight change: Changing the ratio affects new sessions. Existing browser sessions remain attached to the backend stored in their cookie.

Typical Use Cases

  • Applications that store session data locally on the server.
  • A/B testing where each user must remain on the same application version.
  • Gradual rollout of a new release to a controlled percentage of users.
  • Applications where switching a user between backends could interrupt an active workflow.
  • Testing a new backend with a small share of new visitors before increasing traffic.

Important Considerations

  • Sticky Sessions maintains affinity but does not synchronise application files, databases, or server configuration.
  • The two backends may run different application versions for A/B testing, but each version must remain compatible with shared services and data.
  • Deleting cookies or allowing the session to expire causes the user to be treated as a new visitor.
  • If an assigned backend becomes unavailable, routing behaviour depends on the configured health checks and Traffic Distributor settings.
  • For fully stateless applications with shared session storage, Round Robin may provide simpler and more even request distribution.
Session storage: Sticky Sessions reduces the need for shared session storage, but centralised sessions can provide better resilience when a backend fails.

What’s next?