Cache key strategies in Spring Boot - Step-by-Step Execution

Concept Flow - Cache key strategies

Start: Method call

↓

Generate Cache Key

↓

Check Cache for Key

↓

Return Cached

↓

Return Result

↓

End

This flow shows how a cache key is generated and used to check cache before method execution, returning cached data if available or storing new data after execution.

Execution Sample

Spring Boot

@Cacheable(value = "users", key = "#userId")
public User getUser(String userId) {
    // fetch user from DB
    return userRepository.findById(userId);
}

This code caches the result of getUser method using userId as the cache key.

Execution Table

Step	Action	Cache Key Generated	Cache Hit?	Method Executed	Cache Updated	Returned Value
1	Call getUser("123")	"123"	No	Yes	Yes	User object for 123
2	Call getUser("123") again	"123"	Yes	No	No	User object for 123
3	Call getUser("456")	"456"	No	Yes	Yes	User object for 456
4	Call getUser(null)	"null"	No	Yes	Yes	User object for null
5	Call getUser("123") again	"123"	Yes	No	No	User object for 123

💡 Execution stops when method calls end; cache keys determine if method runs or cached data returns.

Variable Tracker

Variable	Start	After Call 1	After Call 2	After Call 3	After Call 4	After Call 5
cache	{}	{"123": User123}	{"123": User123}	{"123": User123, "456": User456}	{"123": User123, "456": User456, "null": UserNull}	{"123": User123, "456": User456, "null": UserNull}
cacheKey	N/A	"123"	"123"	"456"	"null"	"123"
methodExecuted	N/A	true	false	true	true	false

Key Moments - 3 Insights

Why does the method not execute on the second call with the same key?

Because the cache key "123" was found in cache (see execution_table step 2), so cached data is returned without running the method.

What happens if the cache key is null or unexpected?

The key "null" is treated as a string key (step 4), so caching still works but be careful to handle null keys properly.

Why is the cache updated only when the method executes?

Cache updates happen after method execution to store fresh results (steps 1, 3, 4). If cache hit occurs, no update is needed.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cache key generated at step 3?

A "123"

B "null"

C "456"

D No key generated

💡 Hint

Check the 'Cache Key Generated' column at step 3 in execution_table.

At which step does the method execute because the cache did not have the key?

A Step 2

B Step 1

C Step 5

D Step 4

💡 Hint

Look at 'Cache Hit?' and 'Method Executed' columns in execution_table.

If the cache key was changed to include method name, how would the cache keys look?

A "getUser:123"

B "123"

C "user:123"

D "method123"

💡 Hint

Think about adding method name prefix to keys for uniqueness.

Concept Snapshot

Cache key strategies in Spring Boot:
- Use @Cacheable with 'key' to define cache keys.
- Cache key uniquely identifies method input.
- On method call, key is generated and cache checked.
- If key found, return cached result.
- If not, execute method and store result with key.
- Handle null keys carefully to avoid collisions.

Full Transcript

This visual execution shows how Spring Boot cache keys work. When a method annotated with @Cacheable is called, a cache key is generated from the method parameters. The cache is checked for this key. If the key exists, the cached result is returned immediately without running the method again. If the key does not exist, the method runs, and its result is stored in the cache with that key. This process repeats for each method call. The cache key must uniquely identify the input to avoid wrong data returns. Null or unexpected keys are treated as strings but should be handled carefully. This strategy improves performance by avoiding repeated expensive method executions.

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