Redis: What It Is and When to Use It

Direct Answer

Redis is an in-memory data store that supports strings and richer structures such as hashes, sets, sorted sets, streams, and geospatial indexes. Java backends commonly use it for caches, sessions, rate limits, counters, and messaging. Its latency and durability depend on the command, data size, network, persistence, replication, and deployment settings, so benchmark the real workload.

Code Example

// Add dependency: spring-boot-starter-data-redis

@Service
public class ProductService {
    private final ProductRepository repository;

    @Cacheable(value = "products", key = "#id")
    public Optional<Product> findById(Long id) {
        // Expensive database query - Redis caches the result
        return repository.findById(id);
    }

    @CacheEvict(value = "products", key = "#product.id")
    public Product update(Product product) {
        return repository.save(product);
    }
}

@Configuration
@EnableCaching
public class RedisConfig {
    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
        return RedisCacheManager.builder(factory)
            .cacheDefaults(RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofMinutes(10)))  // Cache expires after 10 minutes
            .build();
    }
}

Common Mistakes & Pitfalls

• Assuming Redis is always only a cache: it can be a primary database in a design that explicitly meets its persistence and recovery needs.
• Assuming one command makes a workflow atomic: read-then-write sequences can race even though each command is atomic.
• Caching without invalidation: define how writes update or evict cached values and how much staleness is acceptable.
• Confusing Pub/Sub with a durable queue: disconnected subscribers miss Pub/Sub messages; use Streams or another broker when retention and acknowledgement matter.
• Ignoring memory and eviction: set memory policy deliberately and monitor value growth, hot keys, latency, persistence, and failover.