Redis Key Format Migration Causing Cache Miss Avalanches

System Design Interview•~30 min read•medium

Developer changing Redis cache key convention from 'user:101' to 'v2:user:101' in a new software release.

1. Understand Requirements & Scope

Developer changing Redis cache key convention from 'user:101' to 'v2:user:101' in a new software release. Failure cascade dynamic: 100k QPS → TTL Expiration → Cache Miss Herd → Origin Slam → 💥 DB Meltdown.

Functional Requirements:

Operational Invariant: "Never alter live cache key naming schemes without implementing dual- read fallback or pre-warming to prevent cache avalanches."
Production Hardening: Implement Dual-Read / Lazy-Migration: v2 code checks 'v2:user:101'; if missing, it checks fallback key 'user:101' and migrates the key forward asynchronously, or pre-warm new keys
Prevent cascading failure by isolating downstream degradation at the ingress boundary.

2. Back-of-the-Envelope Capacity Estimation

• Incident Scenario Baseline: Developer changing Redis cache key convention from 'user:101' to 'v2:user:101' in a new software release.

• Failure Cascade Path: 100k QPS → TTL Expiration → Cache Miss Herd → Origin Slam → 💥 DB Meltdown

• Sub-millisecond rejection / shed latency for overloaded requests

3. High-Level Architecture Flow

Implement Dual-Read / Lazy-Migration: v2 code checks 'v2:user:101'; if missing, it checks fallback key 'user:101' and migrates the key forward asynchronously, or pre-warm new keys via background scripts before traffic cutover . Invariant: "Never alter live cache key naming schemes without implementing dual- read fallback or pre-warming to prevent cache avalanches."

Ingress → Bounded Admission Controller → Adaptive Concurrency / Queue Gate → Protected Worker Engine; Overload Shed Path → HTTP 429 / Circuit Fallback (<0.1ms).

Fig 1. Architecture data flow and component topology.

4. Production Implementation & Code

// HARDENED: Fast local Bloom filter / Redis revocation list verification
Claims claims = Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody();
if (revocationBloomFilter.mightContain(claims.getId()) && redis.exists("revoked:" + claims.getId())) {
    throw new SecurityException("Revoked token access attempt rejected");
}

Hardened Implementation Sequence

Ingress Boundary Defense: Implement Dual-Read / Lazy-Migration: v2 code checks 'v2:user:101'; if missing, it checks fallback key 'user:101' and migrates the key forward asynchr
Failure Containment: Eliminate unconstrained buffering and propagate physical backpressure.
Invariant Enforcement: Never alter live cache key naming schemes without implementing dual- read fallback or pre-warming to prevent cache avalanches.

5. Key Decisions & Operational Mitigations

Architectural Decisions & Trade-Offs

•Ingress Admission: Naive unconstrained buffering causes queue bloat and GC exhaustion. Mitigation: Bounded ingress gate with fast non-blocking shedding.
•Resource Strategy: Static capacity allocations collapse under brownouts. Mitigation: Dynamic adaptive limits scaling to real-time physical bounds.
•Outage Impact: Cascading lock convoys and memory saturation. Mitigation: Isolated failure domains keep P99 latency flat and protected.

Operational Hazards & Mitigations

•Cascading Failure: When v2 code deploys, 100% of lookups for 'v2:user:*' miss the cache. The entire 50,000 QPS user read traffic penetrates directly to the primary database, crashing the database within 5 seconds.
•Breakdown Chain: 100k QPS → TTL Expiration → Cache Miss Herd → Origin Slam → 💥 DB Meltdown
•Shedding Failure: Without fast rejection at the boundary, queued dead work triggers multi-second GC pauses, CPU thrashing, and cascading 504 Gateway Timeouts.

Interactive Knowledge Check • Question 1 of 3↓

Interactive Practice Quiz•Question 1 of 3

intermediate

Canary vs Blue-Green Release Strategies

What is the key advantage of Canary Deployments over Blue-Green Deployments for large-scale microservice clusters?