Spring Middleware provides a Redis-based cache module for Spring Boot microservices. It adds annotation-driven TTL configuration, runtime cache inspection, Micrometer-backed statistics, and programmatic cache operations while keeping caching behavior explicit and observable.
The cache module extends Spring caching with Redis-specific helpers and runtime introspection. It is designed to keep cache behavior explicit instead of scattering TTL rules, statistics access, and cache clearing logic across services.
@Cacheable.Services declare cacheable methods as usual, then optionally add Redis-specific TTL metadata. The module collects that information at startup and wires the Redis cache manager accordingly.
Cache configuration stays close to the application code, but the module translates it into Redis cache manager settings at startup.
Use Spring's @Cacheable("my-cache") on the method as usual.
Optionally annotate the same method with @RedisCacheConfiguration.
RedisCacheConfigurationSupport scans methods and customizes the Redis cache manager builder.
The module uses reflection to find methods annotated with both
@Cacheable and @RedisCacheConfiguration,
resolves TTL values, and registers per-cache settings.
Once configured, cache statistics and cache operations can be observed and managed through the service API or the built-in controller endpoints.
Redis caching builds on Spring cache configuration. Redis infrastructure is assumed to be configured separately.
spring:
cache:
type: redis
redis:
enable-statistics: true@Cacheable("catalog-events")
@RedisCacheConfiguration(
ttlString = "${CACHE_TTL_SECONDS:300}",
chronoUnitString = "SECONDS"
)
List<Item> findByCatalogId(UUID catalogId) { ... }ttl — numeric TTLchronoUnit — time unitttlString — placeholder-based TTLchronoUnitString — placeholder-based time unit
Prefer ttlString with environment placeholders in production
so cache TTLs can be tuned without code changes.
The module exposes runtime information about caches and can integrate with Micrometer metrics when statistics are enabled.
Runtime statistics include hit, miss, pending, and puts through the
CacheInformationStatistics DTO.
The service reads meters such as cache.gets and cache.puts
to expose cache behavior programmatically.
The module can expose known cache names and their Redis configuration parameters at runtime.
A small REST API is available under /cache for inspection and cache clearing.
Returns a collection of CacheInformationStatistics,
optionally filtered by cache name.
Returns the current Redis cache configuration parameters known by the module.
Clears the named cache and returns whether the operation succeeded.
Services can interact with runtime cache information through the CacheService.
@Autowired
private CacheService cacheService;
cacheService.clearCache("catalog-events");
Collection<CacheInformationStatistics> stats =
cacheService.getCacheInformationStadistics(
CacheInformationStadisticsFilter.builder()
.cacheNames(List.of("catalog-events"))
.build()
);The module can be extended programmatically and includes a default JSON serializer suited for complex cached objects.
RedisCacheConfigurationSupport#getSpecificRedisCacheConfigurations()
can be overridden by framework modules to add extra cache configurations.
The module registers a GenericJackson2JsonRedisSerializer backed
by an ObjectMapper configured for JDK8 and Java time types,
with polymorphic typing enabled.
Cache effectiveness depends on naming, TTL control, statistics usage, and serialization choices.
Keep cache responsibilities focused and avoid mixing unrelated workloads in one cache.
Use spring.cache.redis.enable-statistics when you need runtime visibility,
but avoid unnecessary overhead.
Use placeholder-based TTL configuration so runtime tuning does not require code changes.
The cache module is centered around annotation processing, runtime cache configuration, and operational APIs.
.../cache/annotations/RedisCacheConfiguration.java
.../cache/config/RedisCacheConfigurationSupport.java
.../cache/service/CacheServiceImpl.java