Spring Redis cache key schema: tenant, prefix and rollout version

Treat the key as persisted data

Two service instances using the same Redis database can read each other's entries. The default cache-name prefix separates caches, but it does not separate tenants inside a cache. A key built only from productId can return tenant A's pricing to tenant B if the method's result also depends on tenantId. Cache key design is part of the security boundary, not an optimization detail.

Version representation changes

If the cached value's shape changes between deployments, an older binary may fail to deserialize a newer value while both are live. Put a schema version in the cache namespace, use an explicit serializer, and set a finite TTL so old entries retire. Avoid relying on Java native serialization for an untrusted or cross-language cache. A rolling deployment may temporarily hold both v3 and v4 keys; budget the extra memory. Expiry policy determines how long that overlap lasts.

Check the collision matrix

Test two tenants with the same product ID, two cache names with the same method argument, and both application versions during a rolling release. Inspect the exact bytes or strings written to Redis; a mocked CacheManager cannot prove namespace isolation. The code sketches the key contract, while the project's serializer choice remains explicit application work.

Implementation sketch

@Cacheable(cacheNames = "price-v4",
    key = "#tenantId + ':' + #productId")
public PriceQuote quote(String tenantId, String productId) {
    return pricing.load(tenantId, productId);
}

Cost and verification

Versioned keys temporarily duplicate hot values during rollout. Tenant-specific keys increase cardinality; that memory cost is preferable to returning another tenant's result.

Common Mistakes

• Do not omit a parameter that changes the returned value from the key.
• Do not disable key prefixes when cache names share one Redis database.
• Do not roll out an incompatible value serializer under an unchanged namespace.

Read next

Spring cache keys: separate tenants and test the loader count, Spring Redis cache TTL versus idle expiry: GETEX changes the read contract, Spring cache eviction: invalidate the same tenant key used by the read, Spring JWT tenant claims: reject missing or malformed ownership before conversion.

Related boundary

Spring Data Redis Cluster: key slots change multi-key operations