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.
What does the "Sticky Sessions Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to sticky sessions vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.