Key eviction is what Memorystore does when it runs out of memory. When the instance hits its memory limit and a new write arrives, the system deletes existing keys to make room for the incoming data. This keeps the database available for new writes, but it comes at the cost of losing older information that was already stored. The Professional Cloud Database Engineer exam tends to test whether you understand this behavior and, more specifically, how to avoid it, so it is worth being precise about when eviction happens and what controls it.
Memorystore holds data in memory, and that memory has a fixed capacity for a given instance. As long as there is free space, new keys are simply added. Once the instance reaches its memory limit, it can no longer take on new data without first freeing some up. At that point the system begins removing existing keys to accommodate new incoming write requests. The instance stays online and continues serving writes, but the data that gets dropped is gone. Eviction is therefore not an error condition so much as a defined fallback behavior for a full instance.
Which keys get dropped is determined by the eviction policy. The policy defines how the database behaves when it reaches its memory limit. You can configure different policies depending on what you want to prioritize, such as removing the keys that have been in memory longest or the keys that are accessed least frequently. The choice changes which data survives under pressure, but it does not change the underlying situation that the instance is out of room. A policy decides what to evict, not whether eviction occurs.
There is also a no-eviction option. Under that setting the instance does not delete existing keys to make space, which means writes that would exceed the memory limit are not absorbed by dropping older data. This matters when every key is meant to persist until it naturally expires or is explicitly deleted, rather than being silently removed because the instance ran short on memory.
If you want to avoid the eviction process entirely, the approach is to provision enough memory to store all of your required data. Eviction is a symptom of an undersized instance, so the fix is capacity. Consider an instance whose memory capacity is too small for its workload. Because the space is limited, memory utilization sits near its peak, and when utilization reaches the top the system is forced into eviction and starts dropping data to keep functioning. Increasing the memory capacity of the instance gives the data more room. As the available space grows, the utilization percentage falls, and the instance moves into a no-eviction state where all data stays in memory until it expires naturally or is removed on purpose.
That relationship between scaling and eviction is the part the exam is most likely to probe. A scenario will often describe a Memorystore instance that is losing data under high load, and the reasoning it wants is that utilization has hit capacity and the resolution is to scale the memory up rather than to change something unrelated. Keeping the link between capacity, utilization, and eviction clear is usually enough to answer those questions, and it is a useful framing to carry into the Professional Cloud Database Engineer exam.
Our Professional Cloud Database Engineer course covers Memorystore key eviction alongside Memorystore tiers and sizing, with practice questions that drill these distinctions.
