BenchMark Quizzes by MDFT Pro

Select Redis Eviction Policy for Player Proximity Cache

You work as a Game Development Engineer for MDFT Pro, a well-known training agency that delivers certification courses to students worldwide. Mark, the Gaming Platform Lead, is developing an online multiplayer game for a gamification training course that teaches Azure Cache for Redis concepts. The game includes a feature allowing players to interact with teammates within a certain proximity distance. When players move, the system calculates which other players are in range and caches this proximity data in an Azure Cache for Redis instance to avoid expensive recalculation. The cache should prioritize players based on how recently they moved—recently active players should remain in cache while inactive players can be evicted. Additionally, when players log out of the game, their proximity data should eventually be removed from the cache as it’s no longer accessed, without requiring manual cleanup code.

Which eviction policy should you configure for Azure Cache for Redis?

Choose the correct answer from the options below.

Explanations for each answer:

volatile-ttl is incorrect. The volatile-ttl policy evicts keys with an expiration time set (TTL), prioritizing keys with the shortest remaining time to live. However, this doesn't align with the requirement to prioritize players based on how recently they moved. Players who moved recently should stay in cache longer, not be evicted based on TTL. Additionally, managing TTLs for every player movement would add unnecessary complexity when LRU-based policies naturally handle recency.
allkeys-lru is correct. The allkeys-lru (Least Recently Used) policy evicts the least recently accessed keys from all keys in the cache, regardless of whether they have TTL values set. This perfectly matches the requirement to prioritize players based on how recently they moved—recently active players remain in cache while inactive players are evicted. It also naturally handles logged-out players whose cache entries are no longer accessed, automatically removing them when memory is needed without requiring explicit TTL management.
allkeys-lfu is incorrect. The allkeys-lfu (Least Frequently Used) policy evicts keys based on access frequency, not recency. A player who moves once but stays in the same location would have low frequency and be evicted, while a player who moved frequently in the past but is now inactive would be retained. This doesn't meet the requirement to prioritize based on how recently players moved. LFU is better for scenarios where frequently accessed data should persist regardless of recency.
volatile-lru is incorrect. The volatile-lru policy only evicts keys that have a TTL set, using LRU among those keys. This would require setting expiration times on all cached player proximity data. If some keys don't have TTL values and memory fills up, Redis won't evict any keys, potentially causing out-of-memory errors. The allkeys-lru policy is more appropriate because it works across all keys without requiring TTL management and naturally handles the recency-based prioritization needed.

Learn more about Eviction Policies:

Azure Cache for Redis Memory Management

Practice Exam

Select Redis Eviction Policy for Player Proximity Cache

Discuss this question on social media: