redis-conventions

Defines Redis caching conventions for DDD hexagonal Spring Boot architecture with ports and adapters.

Updated Aug 10, 2026
One-click install
npx skills add https://github.com/LeeHyunWoo02/ProvinceHow --skill redis-conventions-leehyunwoo02
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: redis-conventions
Source: https://github.com/LeeHyunWoo02/ProvinceHow/tree/main/.claude/skills/redis-conventions
Command: npx skills add https://github.com/LeeHyunWoo02/ProvinceHow --skill redis-conventions-leehyunwoo02

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? In a DDD hexagonal Spring Boot codebase, Redis usage often leaks technical details (RedisTemplate, key strings, TTLs) into domain and application layers, causing tight coupling, key cardinality explosions, missing TTLs, and cache failures crashing APIs. This Skill enforces a consistent set of rules for hiding Redis behind domain ports so caches remain swappable and failures stay contained. ## Core Features & Use Cases - Port-based cache design: Defines how to create ...Cache ports for derived caches and ...Repository ports when Redis is the source of truth, with cache keys modeled as value objects. - Adapter implementation rules: Specifies key namespacing (<context>:<purpose>:), TTL selection based on source data refresh cycles, mandatory expire after Hash putAll, and failure-absorption policies. - Consistency and invalidation: Covers evictAll implementation via key enumeration or cursor-based SCAN (never KEYS), invalidation ownership in use cases/batch cleaners, and key versioning when score formulas change. - Use Case: When adding a new derived score cache for a region recommendation feature, use this Skill to design the cache port, choose a normalized key with bounded cardinality, set the TTL, and wire invalidation into the batch job that refreshes the source data. ## Quick Start Use the redis-conventions skill to design a new score cache port and its Redis adapter for the dwelling context, including key naming, TTL, and eviction.

Frequently Asked Questions about redis-conventions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure Redis caching in a hexagonal Spring Boot architecture?

Define a cache port interface in domain/port using domain language, inject only that port into application services, and implement it in infrastructure/cache with a RedisTemplate adapter. Key assembly, TTL, and serialization stay inside the adapter so domain and application layers never know Redis exists.

How should I name Redis keys and set TTLs in Spring Boot?

Use a namespaced format like <context>:<purpose>:<identifiers> with the prefix constant ending in a colon, and bucket continuous values to bound cardinality. Set TTL shorter than or equal to the source data refresh cycle, and never put TTLs on source-of-truth keys where expiry means data loss.

Should I use @Cacheable or explicit cache ports in Spring?

This convention forbids Spring's @Cacheable abstraction because annotations pull caching concerns back into the application layer. Use an explicit port plus adapter instead, which keeps caching swappable and makes the port easy to mock in use-case tests.

Why should I avoid the Redis KEYS command for cache eviction?

KEYS is a blocking O(N) command that stalls Redis, and it returns null or empty sets that can cause NPEs in callers. Enumerate known keys directly when the key space is finite, or use cursor-based SCAN with ScanOptions in a try-with-resources block for pattern matching.

How do I handle Redis failures without breaking my API?

For derived caches, absorb lookup failures as cache misses and swallow save or eviction failures with log.warn, so Redis outages never become API 500s. Source-of-truth repositories are the exception: propagate exceptions to distinguish store failure from genuinely empty data.

How do I test services that depend on Redis caches?

Mock the cache port interface with Mockito or use an in-memory Fake implementation instead of stubbing RedisTemplate's multi-level operations. For adapter tests, verify putAll is followed by expire, empty results are not cached, and lookup exceptions become Optional.empty.