Recently, I faced performance bottlenecks in our high-traffic e-commerce platform during peak sales. Database queries slowed to a crawl under load, prompting me to explore distributed caching solutions. Today, I’ll share practical techniques for implementing Redis caching patterns in Spring Boot applications that significantly improved our system’s resilience and speed.
When scaling applications, caching becomes essential. Redis excels as an in-memory data store for distributed systems due to its speed and atomic operations. Spring Boot simplifies integration through its cache abstraction layer. Let’s examine two fundamental caching patterns I’ve implemented successfully.
Cache-aside pattern operates on read requests. First, check if data exists in cache. If not (cache miss), fetch from database and populate cache. This approach reduces database load dramatically. Here’s how I applied it:
@Cacheable(value = "products", key = "#id")
public Product getProductById(Long id) {
log.info("Fetching from database: Product {}", id);
return productRepository.findById(id).orElseThrow();
}
@CacheEvict(value = "products", key = "#product.id")
public void updateProduct(Product product) {
productRepository.save(product);
}Notice how Spring’s @Cacheable annotation handles the cache retrieval logic. The @CacheEvict ensures stale data gets removed during updates. But what happens when multiple requests simultaneously miss the cache? This “cache stampede” scenario can overload your database. I mitigate it using probabilistic early expiration:
public Product getProductWithStampedeProtection(Long id) {
Product product = cache.get(id, Product.class);
if (product == null) {
if (redisTemplate.opsForValue().setIfAbsent("lock:" + id, "locked", 2, TimeUnit.SECONDS)) {
product = productRepository.findById(id).orElseThrow();
cache.put(id, product, 30 + ThreadLocalRandom.current().nextInt(10), TimeUnit.MINUTES);
} else {
Thread.sleep(50);
return getProductWithStampedeProtection(id);
}
}
return product;
}Write-through pattern synchronizes cache writes with database updates. Every write operation updates both cache and database atomically. This maintains cache freshness but adds write latency. I use it for frequently accessed configuration data:
public void saveProductWriteThrough(Product product) {
productRepository.save(product);
redisTemplate.opsForValue().set("product:" + product.getId(),
product,
Duration.ofMinutes(45));
}For high availability, I configure Redis Sentinel across multiple availability zones. This setup automatically handles failover during node outages:
spring:
redis:
sentinel:
master: redis-cluster
nodes:
- sentinel1:26379
- sentinel2:26379
- sentinel3:26379Monitoring cache performance is crucial. I track these key metrics via Prometheus:
- Cache hit ratio (target > 0.85)
- Eviction counts
- Memory usage
- Latency percentiles
Why does cache invalidation remain challenging? Because business logic determines optimal expiration strategies. For category-based product listings, I use hash tags for efficient bulk invalidation:
@Cacheable(value = "products", key = "'category:' + #categoryId")
public List<Product> getProductsByCategory(Long categoryId) {
// Database query
}TTL configuration requires balancing freshness and load. I implement tiered expiration—30 minutes for product details but 5 minutes for inventory counts. The CacheManager bean allows centralized control:
@Bean
public CacheManager cacheManager(RedisConnectionFactory factory) {
Map<String, RedisCacheConfiguration> configs = new HashMap<>();
configs.put("products", RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(30)));
configs.put("inventory", RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(5)));
return RedisCacheManager.builder(factory)
.withInitialCacheConfigurations(configs)
.build();
}During deployment, remember to clear caches using RedisCacheManager.clearAll(). For zero-downtime updates, I use dual cache layers with blue-green deployment.
These implementations reduced our database load by 72% during Black Friday sales while maintaining 99.98% availability. The cache-aside pattern handled most read traffic, while write-through ensured critical pricing data stayed current. What caching challenges are you facing in your current projects?
I’d love to hear about your caching implementations—share your experiences in the comments below. If this guide helped you, please like and share it with your network. For more hands-on tutorials, follow my profile!
