Learn the vocabulary of pinning a client's requests to the same backend instance.
0 / 5 completed
1 / 5
At standup, a dev mentions a load balancer routing every request from the same client to the same backend instance, so that instance's in-memory session state stays consistent across the client's requests. What is this routing behavior called?
Sticky sessions, also called session affinity, route every request from the same client to the same backend instance, so that instance's in-memory session state, like a shopping cart held only in that process's memory, stays consistent across the client's requests. Round-robin load balancing spreads requests evenly across every instance, which would scatter a client's requests across different instances with different in-memory state. This affinity is a common quick fix for an application that keeps session state in memory instead of a shared store.
2 / 5
During a design review, the team compares routing based on a cookie the load balancer sets identifying which instance a client is pinned to, versus routing based on a hash of the client's source IP address. Which capability does the cookie-based approach provide that the IP-hash approach doesn't?
Cookie-based affinity provides reliable affinity that survives a client's IP address changing, since the pinning identifier travels with the client in a cookie rather than depending on a source IP that can shift, for instance behind a shared corporate NAT or a mobile carrier's network. IP-hash affinity, by contrast, breaks the moment a client's observed IP address changes mid-session. This is why cookie-based affinity is generally the more robust choice when a client's network path isn't guaranteed to stay stable.
3 / 5
In a code review, a dev notices a newly added backend instance has no record of an in-memory session that was created on a different instance before this one was scaled up. What does this represent?
This is exactly the scaling limitation of relying on sticky sessions with in-memory state that isn't shared across instances, since a client pinned to the new instance for the first time will find no trace of a session created on a different instance before scale-up happened. A cache eviction policy is an unrelated concept about discarding cached entries. This limitation is one of the main reasons teams eventually move session state out of process memory and into a shared store instead of relying on sticky sessions alone.
4 / 5
An incident report shows users were logged out unexpectedly during a rolling deploy, because each backend instance's in-memory session store was lost the moment that instance was replaced, with sticky sessions as the only mechanism keeping a client tied to its session. What practice would prevent this?
Moving session state into a shared external store, such as Redis, lets any instance serve a client's session regardless of which instance actually handles a given request, so a rolling deploy replacing an instance no longer destroys that instance's sessions along with it. Continuing to rely solely on sticky sessions and in-memory state is exactly what caused users to be logged out unexpectedly in this incident. This shared store is the standard fix for making session state resilient to instance churn during a deploy or a scaling event.
5 / 5
During a PR review, a teammate asks why the team is migrating to a shared external session store instead of just keeping sticky sessions, which already work today. What is the reasoning?
Sticky sessions tie a client's session to one specific instance's memory, so replacing or losing that instance during a deploy or a scaling event destroys the session along with it. A shared external store decouples the session from any single instance, letting any instance serve any client's session and making the whole system resilient to instances being added, removed, or replaced. The tradeoff is the added latency and operational dependency of a network round trip to the shared store on every request that needs session data.