Cache key strategies in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding default cache key generation in Spring Boot

In Spring Boot's caching abstraction, what does the default cache key consist of when no custom key is specified?

A Only the first method parameter value

B The method parameters

C A random UUID generated for each cache entry

D The method name as a string

💡 Hint

Think about what uniquely identifies a method call with parameters in caching.

By default, Spring Boot uses the method parameters to generate a unique cache key using SimpleKeyGenerator. This ensures that different calls with different parameters are cached separately.

❓ component_behavior

intermediate

Effect of @Cacheable key attribute with SpEL expression

Given the following method in a Spring Boot service:

@Cacheable(value = "users", key = "#user.id")
public User getUser(User user) { ... }

What will be used as the cache key when this method is called?

Spring Boot

@Cacheable(value = "users", key = "#user.id")
public User getUser(User user) { return user; }

A The id property of the user object passed as parameter

B The default key generated from all method parameters

C The entire user object serialized

D The string "#user.id" literally

💡 Hint

Look at the SpEL expression inside the key attribute.

The key attribute uses Spring Expression Language (SpEL). Here, #user.id extracts the id property from the user parameter to use as the cache key.

📝 Syntax

advanced

Correct SpEL syntax for composite cache key

Which of the following @Cacheable key expressions correctly creates a composite key from two method parameters named 'id' and 'type'?

A #id & #type

B #id, #type

C {#id, #type}

D #id + '-' + #type

💡 Hint

Think about how to concatenate strings in SpEL.

In SpEL, the plus sign (+) concatenates strings. So #id + '-' + #type creates a string key combining both parameters separated by a dash.

🔧 Debug

advanced

Identifying cache key error causing cache misses

A developer uses @Cacheable with key = "#user" on a method with a User parameter. The cache never hits even when called with the same User object. What is the most likely cause?

Spring Boot

@Cacheable(value = "users", key = "#user")
public User getUser(User user) { ... }

A User class does not override equals() and hashCode(), so keys differ despite same data

B The key expression "#user" is invalid SpEL syntax causing runtime error

C The cache value name "users" is reserved and causes conflicts

D The method parameter must be primitive types only for caching

💡 Hint

Think about how objects are compared as keys in caches.

When using an object as a cache key, it must properly implement equals() and hashCode(). Otherwise, different instances with same data are treated as different keys, causing cache misses.

❓ state_output

expert

Cache key behavior with complex nested parameters

Consider a method annotated with @Cacheable(value = "orders") that takes an Order object with nested Customer object. The key is set as "#order.customer.id". If two different Order objects have the same Customer id, what will happen when caching?

Spring Boot

@Cacheable(value = "orders", key = "#order.customer.id")
public Order getOrder(Order order) { ... }

A Each call creates a separate cache entry because the Order objects differ

B Cache will throw an error due to nested property access in key

C Both calls will share the same cache entry because the key is the same customer id

D Cache will ignore the key and use default key generation

💡 Hint

Focus on what the key expression evaluates to.

The key expression uses only the customer id, so different Order objects with the same customer id will map to the same cache key, sharing the cached result.

Practice

1. What is the main purpose of a cache key in Spring Boot caching?

easy

A. To define the cache size limit

B. To store the actual data in the cache

C. To uniquely identify cached data for quick retrieval

D. To clear the cache automatically

Solution

1. Step 1: Understand cache key role

   A cache key uniquely identifies the cached data so the system can find it quickly without confusion.

2. Step 2: Differentiate from other cache functions

   Cache keys do not store data or control cache size; they only act as unique identifiers.

3. Final Answer:

   To uniquely identify cached data for quick retrieval -> Option C

4. Quick Check:

   Cache key = unique identifier [OK]

Hint: Cache keys uniquely identify data to find it fast [OK]

Common Mistakes:

• Thinking cache keys store data
• Confusing keys with cache size settings
• Assuming keys clear cache automatically

2. Which of the following is the correct way to specify a cache key using Spring Expression Language (SpEL) in the @Cacheable annotation?

easy

A. @Cacheable(key = "#user.id")

B. @Cacheable(key = user.id)

C. @Cacheable(key = "user.id")

D. @Cacheable(key = #user.id)

Solution

1. Step 1: Recognize SpEL syntax in @Cacheable

   SpEL expressions must be inside double quotes and start with # to reference method parameters.

2. Step 2: Check each option

   @Cacheable(key = "#user.id") correctly uses "#user.id" as a string with # for SpEL. @Cacheable(key = user.id) misses quotes, the option with "user.id" misses #, @Cacheable(key = #user.id) misses quotes.

3. Final Answer:

   @Cacheable(key = "#user.id") -> Option A

4. Quick Check:

   SpEL key syntax = quoted string with # [OK]

Hint: SpEL keys need quotes and # before variable [OK]

Common Mistakes:

• Omitting quotes around SpEL expression
• Forgetting # before parameter name
• Using plain variable without SpEL syntax

3. Given the method annotated as @Cacheable(value = "users", key = "#id"), what will be the cache key when calling getUser(42)?

medium

A. "id"

B. 42

C. "#id"

D. null

Solution

1. Step 1: Understand key expression #id

   The key uses SpEL #id which means the method parameter named id's value is used as the key.

2. Step 2: Substitute method call parameter

   Calling getUser(42) means id = 42, so the cache key is 42 (an integer).

3. Final Answer:

   42 -> Option B

4. Quick Check:

   Key = parameter value 42 [OK]

Hint: Cache key #param uses actual parameter value [OK]

Common Mistakes:

• Using the string '#id' instead of parameter value
• Confusing key with parameter name only
• Assuming null key if not specified

4. Identify the error in this cache key definition: @Cacheable(value = "items", key = "#item.id + #item.name")

medium

A. SpEL expressions cannot concatenate strings with + operator

B. Missing parentheses around the expression

C. The key must be a constant string, not an expression

D. Using + operator without converting to string may cause wrong key

Solution

1. Step 1: Analyze SpEL expression with + operator

   In SpEL, + can add numbers or concatenate strings. If item.id is numeric, adding to item.name (string) may cause type issues.

2. Step 2: Understand type conversion in keys

   Without explicit string conversion, adding number + string may produce unexpected keys or errors.

3. Final Answer:

   Using + operator without converting to string may cause wrong key -> Option D

4. Quick Check:

   Type mismatch in key expression = error [OK]

Hint: Convert all parts to string before concatenation in keys [OK]

Common Mistakes:

• Assuming + always concatenates strings
• Not converting numeric parts to string explicitly
• Thinking key must be constant string only

5. You want to cache results of a method that takes two parameters: userId (Long) and filter (String). Which cache key strategy ensures unique keys for each combination?

hard

A. Use key = "T(java.util.Objects).hash(#userId, #filter)"

B. Use key = "#userId + #filter" without conversion

C. Use key = "#userId" only

D. Use key = "#filter" only

Solution

1. Step 1: Understand need for unique keys per parameter combo

   Using only one parameter as key risks collisions when other parameter changes.

2. Step 2: Evaluate options for combining parameters

   Use key = "#userId + #filter" without explicit conversion risks type issues. Use key = "T(java.util.Objects).hash(#userId, #filter)" uses Java's Objects.hash to combine both safely. Using only one parameter causes collisions.

3. Final Answer:

   Use key = "T(java.util.Objects).hash(#userId, #filter)" -> Option A

4. Quick Check:

   Combine keys safely with Objects.hash [OK]

Hint: Use Objects.hash to combine multiple parameters safely [OK]

Common Mistakes:

• Concatenating keys without type safety
• Using only one parameter as key causing collisions
• Ignoring proper SpEL syntax for static method calls