Cache configuration in Spring Boot - Step-by-Step Execution

Concept Flow - Cache configuration

Start Application

↓

Enable Cache Support

↓

Define Cache Manager

↓

Annotate Methods with @Cacheable

↓

Method Called

↓

Check Cache for Key

↓

Return Cached

↓

Return Result

↓

End Call

This flow shows how Spring Boot enables caching: it checks cache before method runs, returns cached data if found, otherwise runs method and caches result.

Execution Sample

Spring Boot

@SpringBootApplication
@EnableCaching
public class App {
  @Cacheable("books")
  public Book findBook(String isbn) {
    // fetch book from DB
    return null; // placeholder return
  }
}

This code enables caching and caches results of findBook method by ISBN.

Execution Table

Step	Action	Cache State	Method Called	Result Returned
1	Application starts with @EnableCaching	Cache empty	No	No result
2	Call findBook("123")	Cache empty	Yes - fetch from DB	Book object fetched
3	Store Book in cache with key "123"	Cache has key "123"	No	No result
4	Call findBook("123") again	Cache has key "123"	No - return cached	Book object from cache
5	Call findBook("456")	Cache has key "123"	Yes - fetch from DB	Book object fetched
6	Store Book in cache with key "456"	Cache has keys "123", "456"	No	No result
7	Call findBook("789")	Cache has keys "123", "456"	Yes - fetch from DB	Book object fetched
8	Store Book in cache with key "789"	Cache has keys "123", "456", "789"	No	No result
9	Call findBook("123") again	Cache has keys "123", "456", "789"	No - return cached	Book object from cache

💡 Execution stops when no more method calls are made.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	After Step 6	After Step 7	After Step 8	Final
Cache Keys	[]	[]	["123"]	["123"]	["123", "456"]	["123", "456"]	["123", "456", "789"]	["123", "456", "789"]

Key Moments - 3 Insights

Why does the method not run every time it is called?

Because after the first call, the result is stored in cache (see step 3), so subsequent calls with the same key return cached data (see step 4).

What happens if a new key is used in the method call?

The method runs again to fetch fresh data (see step 5), then the result is cached for that new key (step 6).

Does the cache grow indefinitely?

By default, cache stores all keys unless configured otherwise. This example shows keys accumulating (see variable_tracker).

Visual Quiz - 3 Questions

Look at the execution table, what is the cache state after step 3?

A Cache has keys "123" and "456"

B Cache is empty

C Cache has key "123"

D Cache has keys "123", "456", "789"

💡 Hint

Check the 'Cache State' column in row for step 3.

At which step does the method run to fetch data for key "456"?

A Step 4

B Step 5

C Step 7

D Step 9

💡 Hint

Look for 'Method Called' = Yes and 'Method Called' column in execution_table.

If the cache was cleared after step 6, what would happen at step 9?

A Method would run again to fetch data

B Cached data would be returned

C An error would occur

D Nothing would happen

💡 Hint

Refer to variable_tracker and execution_table for cache keys presence.

Concept Snapshot

Spring Boot Cache Configuration:
- Add @EnableCaching to enable cache support
- Define cache manager bean or use defaults
- Use @Cacheable on methods to cache results
- On method call, cache checked first
- If cached, return cached result
- If not, run method and store result in cache
- Cache keys are method parameters by default

Full Transcript

This visual execution shows how Spring Boot cache configuration works. When the application starts with @EnableCaching, the cache is empty. Calling a method annotated with @Cacheable checks if the result for the given key is in cache. If not, the method runs and the result is stored in cache. Subsequent calls with the same key return cached data without running the method again. New keys cause the method to run and cache new results. The cache grows as new keys are added unless configured otherwise.

Practice

1. What is the primary purpose of using cache configuration in a Spring Boot application?

easy

A. To temporarily store data and speed up application performance

B. To permanently save data to the database

C. To encrypt sensitive data before sending it

D. To manage user authentication and authorization

Solution

1. Step 1: Understand caching concept

   Caching stores data temporarily to avoid repeated processing or fetching.

2. Step 2: Identify caching benefit in Spring Boot

   It speeds up the app by reusing stored data instead of recalculating or fetching again.

3. Final Answer:

   To temporarily store data and speed up application performance -> Option A

4. Quick Check:

   Cache = Temporary storage for speed [OK]

Hint: Cache means temporary storage to speed up apps [OK]

Common Mistakes:

• Confusing cache with permanent database storage
• Thinking cache encrypts data
• Mixing cache with security features

2. Which annotation is used to enable caching support in a Spring Boot application?

easy

A. @EnableCaching

B. @Cacheable

C. @CacheConfig

D. @CachePut

Solution

1. Step 1: Recall Spring Boot caching setup

   To activate caching, Spring Boot requires a special annotation on a configuration class.

2. Step 2: Identify the correct annotation

   @EnableCaching enables the caching mechanism globally in the app.

3. Final Answer:

   @EnableCaching -> Option A

4. Quick Check:

   @EnableCaching activates caching [OK]

Hint: Enable caching with @EnableCaching annotation [OK]

Common Mistakes:

• Using @Cacheable to enable caching (it marks methods, not enable)
• Confusing @CachePut with enabling caching
• Thinking @CacheConfig enables caching globally

3. Given the code below, what will be the output when getUser(1) is called twice?

@Cacheable("users")
public User getUser(int id) {
    System.out.println("Fetching user from DB");
    return new User(id, "Name" + id);
}

medium

A. Fetching user from DB printed twice, two User objects returned

B. No output printed, both calls return null

C. Fetching user from DB printed once, but both calls create new User

D. Fetching user from DB printed once, second call returns cached User

Solution

1. Step 1: Understand @Cacheable behavior

   The first call runs the method and caches the result; subsequent calls return cached data.

2. Step 2: Analyze output for two calls

   "Fetching user from DB" prints only once on first call; second call uses cache, no print.

3. Final Answer:

   Fetching user from DB printed once, second call returns cached User -> Option D

4. Quick Check:

   @Cacheable caches after first call [OK]

Hint: First call runs method, next calls use cache [OK]

Common Mistakes:

• Assuming method runs every time ignoring cache
• Thinking cache returns null if not found
• Confusing @Cacheable with @CachePut behavior

4. Identify the error in this cache configuration snippet:

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        return new CacheManager();
    }
}

medium

A. Missing @Cacheable annotation on methods

B. CacheManager is an interface and cannot be instantiated directly

C. Missing @EnableCaching annotation

D. CacheManager bean method should be static

Solution

1. Step 1: Check CacheManager instantiation

   CacheManager is an interface; you cannot create it with new CacheManager().

2. Step 2: Correct way to create CacheManager bean

   You must return a concrete implementation like ConcurrentMapCacheManager.

3. Final Answer:

   CacheManager is an interface and cannot be instantiated directly -> Option B

4. Quick Check:

   CacheManager interface needs implementation [OK]

Hint: CacheManager is interface; use implementation class [OK]

Common Mistakes:

• Trying to instantiate interface directly
• Forgetting to add @EnableCaching
• Thinking @Cacheable is needed on config class

5. You want to configure a cache in Spring Boot that stores user data and expires entries after 10 minutes. Which approach correctly combines cache configuration and expiration?

hard

A. Use @EnableCaching and define a ConcurrentMapCacheManager bean with TTL set to 10 minutes

B. Use @CachePut and manually remove cache entries after 10 minutes

C. Use @EnableCaching and configure a CaffeineCacheManager with expiry policy of 10 minutes

D. Use @Cacheable with a parameter to set expiration time to 10 minutes

Solution

1. Step 1: Understand cache expiration support

   ConcurrentMapCacheManager does not support TTL (time to live) expiration by default.

2. Step 2: Identify cache manager with TTL support

   CaffeineCacheManager supports expiration policies like 10-minute TTL.

3. Step 3: Evaluate options

   @Cacheable does not accept expiration parameters; @CachePut updates cache but does not manage expiration automatically.

4. Final Answer:

   Use @EnableCaching and configure a CaffeineCacheManager with expiry policy of 10 minutes -> Option C

5. Quick Check:

   CaffeineCacheManager supports TTL expiration [OK]

Hint: Use CaffeineCacheManager for TTL expiration [OK]

Common Mistakes:

• Assuming ConcurrentMapCacheManager supports TTL
• Trying to set expiration via @Cacheable annotation
• Using @CachePut to handle expiration manually