Server
Sticky session
Also called session affinity.
Sticky session is a load balancer rule that sends a visitor to the same backend on each request, usually using a cookie or the client's IP. It exists because the backend keeps that visitor's state in its own memory.
How it is measured
Check the balancer for a persistence setting, such as a cookie named AWSALB or a hash on source IP, and for the lifetime. Then compare request counts per backend: with sticky routing they can be quite uneven.
Test by making ten requests with the cookie jar and ten without. If the first set all hit one node and the second spreads out, stickiness is on.
Worked example
A PHP shop stores carts in files on each server's disk. With 3 servers and no stickiness, a customer adds a mug on server A, then lands on server C and sees an empty basket. About 1 in 3 page loads shows a wrong cart.
Enabling a 1 hour cookie-based sticky rule fixes it. The cost: a campaign sends one big office to server B, which runs at 94 percent CPU while the others idle at 30. Moving carts to Redis later removed the need.
How it differs
A sticky session pins a visitor to one backend. A load balancer is the component that would otherwise spread each request freely. Stickiness excludes even distribution and makes failover lose state. A stateless design excludes the need for it altogether, and session data in a shared store is the usual replacement.
Common errors
Using it to hide state that should be shared. Expecting even load across nodes. Forgetting the visitor loses their session if the backend dies. Setting a lifetime that outlasts deploys. Confusing it with the login session, which is a different thing.
In practice
List what your app keeps in local memory or disk per visitor, and move it to Redis, a database or a signed cookie. Keep stickiness only for the cases that need it, like WebSockets.