Loading published curriculum…

20 · Production engineering and architecture / LESSON 99 OF 102

Caching, eviction, and scheduled work

Caching trades freshness and coordination complexity for reduced repeated work.

Before this lesson: Logs, metrics, traces, and service objectives

Understand the topic

@Cacheable uses a configured cache and proxy interception; self-invocation can bypass it. Choose keys that include every security-relevant dimension such as owner identity. Evict or update entries when underlying data changes and define a freshness policy.

@Scheduled runs within each application instance unless coordinated externally. Several replicas can execute the same job, so make work idempotent or use a scheduler/locking design that enforces the intended ownership. In-memory caches disappear on restart and are not shared across replicas.

EXAMPLE · JAVA

Cache boundary fragment

@org.springframework.cache.annotation.Cacheable(
 cacheNames = "ownerProgress", key = "#p0")
public ProgressSummary summary(long authenticatedOwnerId) {
 return repository.computeSummary(authenticatedOwnerId);
}

What to expect

Requires @EnableCaching, a CacheManager, the DTO, and repository implementation. The owner-based key prevents one owner’s summary being reused for another; define eviction after updates.

YOUR TURN

Put it into practice

  1. 01Cache an owner-scoped progress summary and invalidate it after task completion.
  2. 02Test two owners and two application instances; document freshness and restart behavior.
  3. 03Verify: No cross-owner cached value is returned and updated progress becomes visible under the declared policy.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Caching trades freshness and coordination complexity for reduced repeated work.

  1. 01@Cacheable uses a configured cache and proxy interception; self-invocation can bypass it. Choose keys that include every security-relevant dimension such as owner identity. Evict or update entries when underlying data changes and define a freshness policy.
  2. 02@Scheduled runs within each application instance unless coordinated externally. Several replicas can execute the same job, so make work idempotent or use a scheduler/locking design that enforces the intended ownership. In-memory caches disappear on restart and are not shared across replicas.
  3. 03Trace the example: Requires @EnableCaching, a CacheManager, the DTO, and repository implementation. The owner-based key prevents one owner’s summary being reused for another; define eviction after updates.

A mistake worth avoiding

One user receives another user’s cached summary.

DEBUGGING ROOM

Something broke. Where do you look?

One user receives another user’s cached summary.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Does @Scheduled automatically execute only once across all replicas?

Choose one answer

BUILD IT YOURSELF

Cache an owner-scoped progress summary and invalidate it after task completion.

  1. 1.Cache an owner-scoped progress summary and invalidate it after task completion.
  2. 2.Test two owners and two application instances; document freshness and restart behavior.
  3. 3.Reproduce this failure, then repair it: One user receives another user’s cached summary.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Does @Scheduled automatically execute only once across all replicas?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

No cross-owner cached value is returned and updated progress becomes visible under the declared policy.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references