Decorator for caching

Direct Answer

A caching repository decorator implements the repository contract, wraps the real repository, returns a cached value on a valid hit, and delegates on a miss. Writes usually evict or update affected keys only after the database succeeds, but database and cache changes are not atomic, so stale data, concurrent misses, failure recovery, TTL, and multi-instance invalidation need an explicit policy.

Code Example

final class CachingUserRepository implements UserRepository {
    private final UserRepository delegate;
    private final ConcurrentMap<Long, User> cache = new ConcurrentHashMap<>();

    CachingUserRepository(UserRepository delegate) {
        this.delegate = delegate;
    }

    public Optional<User> findById(Long id) {
        User cached = cache.get(id);
        if (cached != null) return Optional.of(cached);

        Optional<User> loaded = delegate.findById(id);
        loaded.ifPresent(user -> cache.put(id, user));
        return loaded;
    }

    public User save(User user) {
        User saved = delegate.save(user); // transaction must succeed first
        cache.remove(saved.id());         // reload on the next read
        return saved;
    }

    public void deleteById(Long id) {
        delegate.deleteById(id);
        cache.remove(id);
    }
}

This is a teaching example, not a complete production cache: it has no TTL, size bound, cross-instance invalidation, or stampede control.

Common Mistakes & Pitfalls

• Calling a concurrent map a complete cache: it has no expiry, size bound, or multi-instance coherence.
• Assuming write-through is atomic: the database can succeed while the cache update fails.
• Using containsKey followed by get: a concurrent removal can change the result between calls; read once.
• Caching mutable entities directly: later mutation can silently change the cached value.
• Ignoring misses and stampedes: decide whether absence is cached and how concurrent loads are combined.