Distributed Caching in Spring Boot: Hazelcast vs Infinispan vs Redis
Spring's cache abstraction makes a specific promise: annotate a method with @Cacheable, and the business code never knows or cares which product is actually storing the cached value. This post puts that promise to the test with three genuinely different backends — Hazelcast and Infinispan, both embedded in-process, and Redis, a real out-of-process server — running the exact same service class and the exact same test logic against each, swapped only by which CacheManager bean wins. The interesting part turned out not to be the happy path, which is identical across all three, but three real failures along the way: a missing transitive dependency that breaks startup regardless of which backend you asked for, a JMX collision between embedded cache managers sharing one test JVM, and one backend that — unlike the other two — refuses to create a cache you never declared. Versions used in this post. Spring Boot 4.1.1 · com.hazelcast:hazelcast-spring 5.5.0 · org.infinispan:infinispan-spring-boot4-starter-embedded 16.1.4 · Redis server 8.8.3 (Testcontainers) · JDK 25 (Temurin) · Testcontainers 2.0.5. All three resolved and verified via mvn dependency:tree and javap against the real jars — none of the class names or artifact coordinates below were assumed from documentation.