Distributed Caching in 2026: Redis vs Valkey vs Dragonfly — System Design Interview Master Guide (Architecture, Patterns & Trade-offs)

One of the most common follow-up questions in senior engineering interviews is: "Walk me through the concurrency model of your chosen cache engine." Here is exactly how to answer for each system.

Single-Threaded Event Loop (Redis 7.x, Early Valkey)

The Redis concurrency model runs all command processing in a single main thread using epoll (Linux) or kqueue (macOS/BSD) for non-blocking I/O multiplexing. All commands are guaranteed to execute atomically without locking — which is why Redis's MULTI/EXEC transactions and Lua scripts work correctly without deadlocks. The fatal limitation: any O(N) or CPU-heavy command (like KEYS *, SORT on large datasets, or computationally expensive Lua scripts) blocks every other client for its entire duration because there is no way to context-switch on the command executor thread.

Multi-Threaded I/O + Single Command Executor (Valkey 8.0)

Valkey 8.0's hybrid threading model uses multiple I/O threads to handle network reads and writes in parallel while preserving a single command execution thread for correctness. This eliminates the I/O bottleneck that throttled Redis on high-connection-count workloads (>10K concurrent clients) while maintaining backward compatibility with all Redis client libraries and the full RESP3 protocol.

Shared-Nothing Multi-Core (Dragonfly)

Dragonfly partitions the key space across N CPU cores (one shard per logical CPU). Each shard runs its own event loop with no cross-shard locking for single-key operations. For multi-key atomic operations that span multiple shards (like MSET, LMOVE, or Lua scripts touching multiple keys), Dragonfly uses a deterministic lock ordering protocol to acquire per-shard vCPU locks in a deadlock-free sequence before executing the multi-shard operation atomically.

Cache Invalidation & Consistency Patterns: The Real Interview Battleground

Phil Karlton's famous quote — "There are only two hard things in Computer Science: cache invalidation and naming things" — is not just a meme. In 2026 system design interviews, failure to clearly articulate cache consistency guarantees, invalidation timing, and failure modes is the #1 reason candidates fail the distributed systems round. Here is the complete pattern playbook.

Cache-Aside (Lazy Loading) — Standard Read-Heavy Pattern

The application checks the cache first. On a cache miss, it reads from the database, writes the result to cache with a TTL, and returns. On a cache hit, it returns the cached value directly without touching the database. This pattern provides natural resilience — a full cache outage degrades gracefully to database-only reads. Critical gotcha for interviews: The race condition where two concurrent threads both experience a cache miss, both query the database, and one overwrites the other's fresher result with stale data. Solution: use a cache-level optimistic locking strategy or accept eventual consistency with short TTLs.

Write-Through — Strong Consistency for Write-Heavy Workloads

Every database write is immediately followed by a synchronous cache write. The application waits for both to confirm before responding to the client. This guarantees cache-database consistency at the cost of increased write latency (2 round trips per write). Interview follow-up: What happens when the database write succeeds but the cache write fails? You need an idempotent retry mechanism or a compensating transaction to maintain consistency.

Write-Behind (Write-Back) — Ultra-Low Write Latency with Durability Risk

Writes go to the cache immediately and return to the client. An asynchronous background daemon (or Kafka CDC pipeline using Debezium for database CDC) flushes dirty cache entries to the database in micro-batches. Achieves sub-5ms write p99 latency but introduces data loss risk if the cache node fails before flushing. Suitable for analytics counters, session telemetry, and write-intensive metrics — never for financial transactions or inventory records.

Read-Through with Refresh-Ahead — Eliminating Cache Miss Penalty

The cache layer intercepts all reads and handles database hydration transparently (vs Cache-Aside where the application must handle misses). Refresh-Ahead extends this: the cache predicts which entries will expire soon based on access frequency and preemptively refreshes them before they expire, eliminating the cache miss latency spike for high-traffic keys entirely.

Advanced Failure Mode Patterns You Must Know

Cache Stampede (Thundering Herd) — The Most Common Interview Trick

When a highly-trafficked cached entry expires, dozens to thousands of concurrent requests simultaneously experience a cache miss and simultaneously query the database — hammering it with load it cannot handle. This is called the Thundering Herd problem or Cache Stampede. In 2026 senior interviews, candidates are expected to know at least 3 mitigation strategies:

1. Distributed Mutex (Singleflight Pattern): Only the first request to miss the cache acquires a distributed lock (using SET key value NX PX 5000 — an atomic "set if not exists" with expiry in Valkey/Redis). All subsequent requests for the same key wait for the lock-holder to repopulate the cache. Golang's singleflight package implements this natively at the application layer.
2. Probabilistic Early Expiration (XFetch / Jittered TTL): Before an item's TTL expires, the system uses the XFetch algorithm: P(recompute) = beta * max(0, expire_time - current_time) * log(recompute_time). High-traffic items are proactively recomputed before they expire, spreading the refresh load smoothly over time rather than in a cliff-edge miss spike.
3. Stale-While-Revalidate (SWR): After a cache entry expires, continue serving the stale value to clients while a single background thread asynchronously recomputes and refreshes it. This completely eliminates user-visible latency from cache misses for non-critical-freshness data like recommendation lists, trending feeds, or homepage content.

Cache Penetration — Queries for Non-Existent Keys

An attacker or buggy client repeatedly queries for keys that do not exist in either the cache or the database. Every request bypasses the cache and hits the database. Solutions: Cache null sentinel values (store an explicit "CACHE_MISS" string with a short 60-second TTL), or deploy a Bloom Filter (Valkey's native BF.EXISTS command from the RedisBloom successor module) in front of the cache to reject queries for provably non-existent keys with zero database hits.

Hot Key Problem — Uneven Load Distribution

A single cache key (e.g., a celebrity's profile during a viral moment, a trending product, or a breaking news article) receives millions of requests per second — exceeding the memory bandwidth and CPU capacity of the single cache node that owns that key. Solutions: Key replication with local sharding (distribute 100 replicas of hot_key as hot_key:shard_0 through hot_key:shard_99 and randomly read from any replica), or application-layer local caching (L1 in-process cache using Caffeine/Guava Cache that absorbs 95% of hot-key reads before they even reach the distributed cache layer).

Distributed Locks with Redlock: The Senior Engineer's Answer

When asked "How do you implement distributed mutual exclusion across multiple services?", the 2026 answer is the Redlock Algorithm (proposed by Salvatore Sanfilippo, Redis's original author):

1. Acquire the lock on N/2 + 1 independent cache nodes (majority quorum) within a validity timeout window using SET resource_name my_random_value NX PX 30000.
2. The lock is considered acquired only if a majority of nodes respond with success and the total acquisition time is less than the lock's validity TTL minus clock drift tolerance.
3. Release the lock on all nodes using a Lua script that atomically checks token ownership before deleting: if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end.

Key interview nuance: Martin Kleppmann's critique of Redlock (insufficient safety under network partitions and clock drift) shows genuine depth. Mention that for true linearizable distributed locking, you'd prefer Apache Zookeeper sequential znodes, etcd lease-based locks, or Google Chubby-style consensus locks — but for probabilistic correctness under typical operational conditions, Redlock with monotonic clock-based validity checking is sufficient for most production use cases.

Cache Architecture Selection Matrix for System Design Interviews

Memory & Eviction Policy: Don't Lose Points on Fundamentals

A surprisingly common failure in system design interviews: candidates design a caching layer with no mention of how the cache handles memory pressure. Always state your eviction policy upfront and justify it:

• allkeys-lru: Evict the globally least recently used key across all keys. Best for general-purpose caches where all data has roughly equal value.
• volatile-lru: Only evict keys with an explicit TTL set, using LRU ordering. Protects keys without TTL from eviction — useful when some keys are permanent configuration data and others are ephemeral session data.
• allkeys-lfu (2026 Preferred): Evict the least frequently used key globally. Valkey 8.0 and Dragonfly implement a Morris Counter-based approximate LFU algorithm that adapts to access frequency shifts in real-time. Dramatically outperforms LRU on workloads with strong temporal locality (hot items stay hot for extended periods).

Always size your cache explicitly in interviews: estimated_key_count × average_value_bytes × 1.3 (encoding overhead factor) = minimum_cache_RAM_required. For 100M cached session objects averaging 500 bytes each: 100M × 500B × 1.3 = 65GB RAM — which maps to a 2-node Dragonfly cluster with 128GB RAM per node, or an 8-node Valkey cluster with 32GB RAM per node.