In-Memory Caching Architecture: Valkey 8 & Redis Cluster Sharding, Persistence & Eviction Tuning

1. Valkey 8 vs. Redis: Architectural Continuity & Multi-Threaded I/O

Following the licensing change of Redis 7.4+ to dual RSALv2/SSPLv1, the Linux Foundation launched Valkey—an open-source (BSD-3-Clause), drop-in wire-compatible fork backed by AWS, Google Cloud, Oracle, Ericsson, and Alibaba Cloud.

While the core command execution engine in both Valkey and Redis remains single-threaded and atomic (eliminating lock contention on complex data structures like Sorted Sets ZSET, Streams, and Hashes), Valkey 8.0 introduces improved asynchronous multi-threaded network I/O and TLS offloading alongside dual-channel replication (allowing replica synchronization to proceed concurrently without blocking RDB snapshot transfers).

2. Choosing Between Primary-Replica (Sentinel) and Cluster Sharding (16,384 Hash Slots)

Do not deploy a multi-shard Cluster topology if your working dataset fits comfortably inside 24 GB to 32 GB of RAM on a single primary node:

| Deployment Topology | Dataset Size Sweet Spot | Multi-Key Operations (MGET, Lua, Transactions) | Failover Mechanism |
| :--- | :--- | :--- | :--- |
| 1 Primary + 2 Replicas + 3 Sentinels | < 32 GB RAM | 100% Supported across all keys without hash-tag restrictions | Sentinel quorum promotes replica in ~3–8 seconds |
| Sharded Cluster (Min 3 Primaries + 3 Replicas) | 32 GB to 1 TB+ RAM | Restricted to keys sharing the same {hash_tag} (CRC16(tag) mod 16384) | Gossip protocol between primary nodes promotes replica automatically |

Why Multi-Key Lua Scripts Break in Sharded Clusters Without Hash Tags

In a sharded cluster (Valkey Cluster Spec), the keyspace is partitioned across 16,384 hash slots using $ ext{Slot} = ext{CRC16}( ext{key}) mod 16384$. If a rate-limiting Lua script (EVAL) or MGET command accesses user:42:profile and user:42:quota, those two strings hash to different slots and throw a CROSSSLOT Keys in request don't hash to the same slot error—unless you wrap the shared tenant identifier in curly braces: {user:42}:profile and {user:42}:quota, which forces the CRC16 hash to evaluate only the substring inside {...}!

3. Linux Kernel Virtual Memory & maxmemory-policy Hardening

The most dangerous production outage on an in-memory cache server occurs when background BGSAVE (RDB snapshot) or BGREWRITEAOF forks a child process (fork()). If Linux vm.overcommit_memory is left at 0 and Transparent Huge Pages (THP) are enabled, copy-on-write page faults during fork() can double memory consumption in seconds and trigger the Linux OOM Killer:

# 1. Mandatory Linux Kernel Sysctl & THP Settings for Valkey / Redis Hosts
echo "vm.overcommit_memory = 1" | sudo tee -a /etc/sysctl.d/99-valkey.conf
echo "net.core.somaxconn = 16384" | sudo tee -a /etc/sysctl.d/99-valkey.conf
sudo sysctl --system
# Disable Transparent Huge Pages (THP) to prevent multi-hundred-millisecond fork latency spikes
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

Selecting the Right maxmemory-policy (Cache vs. Queue/Session Store)

In /etc/valkey/valkey.conf, never leave maxmemory uncapped on a production server. Set maxmemory to 70%–75% of physical RAM (leaving 25%–30% headroom for replica output buffers and copy-on-write fork pages):

# /etc/valkey/valkey.conf — Production High-Throughput Cache Baseline
maxmemory 24gb
maxmemory-policy allkeys-lfu
activedefrag yes
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
io-threads 4
io-threads-do-reads yes
appendonly yes
appendfsync everysec

- Use allkeys-lfu (Windowed Least Frequently Used) or allkeys-lru: When Valkey is used purely as a read-through cache in front of PostgreSQL, where any evicted key can be recomputed from the database.
- Use volatile-lfu or noeviction: When storing both persistent background job queues (BullMQ / Sidekiq with no TTL) and ephemeral cache keys (with EX TTLs) in the same instance—or better yet, isolate persistent job queues into a dedicated instance with maxmemory-policy noeviction so cache pressure never silently drops a queued background job!

4. Preventing Cache Stampedes (Thundering Herd) & Big-Key Latency Spikes

Even with Valkey 8's asynchronous I/O threading (io-threads 4), the core command execution engine remains single-threaded for atomicity. A single HGETALL or SMEMBERS call on a key containing 500,000 elements—or a sudden expiration of a hot cache key—can stall the entire shard for tens of milliseconds.

Production Safeguards & Real-Time Diagnostic Commands

# 1. Scan a live Valkey/Redis node for oversized keys without blocking production traffic (-i 0.05 sleeps 50ms per 100 keys)
valkey-cli --bigkeys -i 0.05
# 2. Inspect commands taking longer than 2 milliseconds (2000 microseconds) in the Slowlog
valkey-cli CONFIG SET slowlog-log-slower-than 2000
valkey-cli SLOWLOG GET 15
# 3. Monitor real-time memory fragmentation ratio and eviction rate
valkey-cli INFO memory | grep -E "used_memory_human|mem_fragmentation_ratio|maxmemory_policy"
valkey-cli INFO stats | grep -E "evicted_keys|keyspace_hits|keyspace_misses"

5. High-Availability Architecture Checklist for Valkey 8 in Production

| Failure Mode | Impact on Application Tier | Architectural Mitigation |
| :--- | :--- | :--- |
| Simultaneous Expiration of Hot Cache Key (Cache Stampede) | Hundreds of concurrent workers query primary PostgreSQL simultaneously | Add random TTL jitter (TTL = 3600 + random(0, 300)) and implement single-flight mutex locking (SET resource:lock 1 NX PX 5000) on cache misses. |
| Linux OOM Killer Terminates valkey-server During Background BGSAVE | Instant cache cold-start and session loss | Set vm.overcommit_memory = 1, cap maxmemory at 70% of physical RAM (leaving 30% for Copy-on-Write fork pages), and disable Transparent Huge Pages (THP). |
| Split-Brain During Network Partition in 2-Node Setup | Two nodes accept conflicting writes | Always deploy an odd number (3 or 5) of Sentinel / Cluster primary nodes across distinct failure domains with min-replicas-to-write 1. |