Lately, I’ve been tackling performance bottlenecks in our Spring Boot applications at work. As traffic grew, database calls became the main culprit for latency spikes. That’s when I turned to Redis for distributed caching—it slashed response times and scaled beautifully across instances. Today, I’ll walk you through practical Redis implementation from initial setup to advanced patterns.

First, let’s configure Redis in Spring Boot. Add these dependencies to your pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
    </dependency>
</dependencies>

Now, configure connection pooling and serialization. Notice how we optimize connection reuse and JSON handling:

@Configuration
@EnableCaching
public class RedisConfig {
    
    @Bean
    public LettuceConnectionFactory connectionFactory() {
        RedisStandaloneConfiguration config = new RedisStandaloneConfiguration("localhost", 6379);
        LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
            .commandTimeout(Duration.ofSeconds(2))
            .useSsl().build();
        
        return new LettuceConnectionFactory(config, clientConfig);
    }
    
    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory());
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        return template;
    }
}

With Redis connected, implement basic caching using Spring’s annotations. Here’s a product service example:

@Service
public class ProductService {
    
    @Cacheable(value = "products", key = "#id")
    public Product getProductById(Long id) {
        // Database fetch simulation
        return productRepository.findById(id).orElseThrow();
    }
    
    @CacheEvict(value = "products", key = "#product.id")
    public void updateProduct(Product product) {
        productRepository.save(product);
    }
}

See how @Cacheable avoids repeated database hits? But what happens when multiple services update the same data? That’s where advanced patterns shine. For cache-aside:

public Product getProductWithCacheAside(Long id) {
    Product product = redisTemplate.opsForValue().get("product:" + id);
    if (product == null) {
        product = database.fetchProduct(id);
        redisTemplate.opsForValue().set("product:" + id, product, Duration.ofMinutes(30));
    }
    return product;
}

Write-behind patterns take this further by batching updates. How might we handle sudden cache expiration floods? Try probabilistic early expiration:

public Product getProductWithStampedeProtection(Long id) {
    Product product = redisTemplate.opsForValue().get("product:" + id);
    if (product == null) {
        synchronized (this) {
            product = redisTemplate.opsForValue().get("product:" + id);
            if (product == null) {
                product = database.fetchProduct(id);
                // Add 10% variance to expiration to avoid simultaneous expiration
                int variance = new Random().nextInt(300);
                redisTemplate.opsForValue().set("product:" + id, product, Duration.ofSeconds(1800 + variance));
            }
        }
    }
    return product;
}

Cache invalidation requires special attention. Use Redis pub/sub for cross-instance synchronization:

@Bean
public RedisMessageListenerContainer container(RedisConnectionFactory factory) {
    RedisMessageListenerContainer container = new RedisMessageListenerContainer();
    container.setConnectionFactory(factory);
    container.addMessageListener(messageListener(), new ChannelTopic("cacheInvalidation"));
    return container;
}

@Bean
public MessageListenerAdapter messageListener() {
    return new MessageListenerAdapter(new CacheInvalidationHandler());
}

For monitoring, leverage Redis CLI commands like INFO stats and SLOWLOG GET. Track keyspace hits/misses and latency percentiles. Notice eviction metrics spiking? Consider adjusting your TTLs or scaling Redis memory.

Common pitfalls include over-caching volatile data and ignoring serialization overhead. Always benchmark different serializers—we found Jackson outperformed Java serialization by 4x in our tests. And remember: cache only idempotent operations. Ever cached a non-idempotent call and faced inconsistencies? I learned that lesson the hard way!

Distributed caching transformed our application performance, cutting 95th percentile latency from 2 seconds to under 150ms. What bottlenecks could Redis solve in your stack? Share your experiences below—I’d love to hear what patterns worked for you. If this helped, consider liking or sharing with your network!