Distributed Caching Architecture: Redis Cluster vs Memcached
As web applications scale to hundreds of thousands of active users, querying relational databases for every page view creates severe I/O bottlenecks and high database CPU utilization. In-memory caching stores hot, frequently accessed data (such as user sessions, catalog items, or API responses) in RAM, dropping query response times from 50 milliseconds to sub-1 millisecond.
Distributed In-Memory Caching Platforms scale horizontally across multi-node server clusters. Redis Cluster provides advanced data structures (Hashes, Sets, Streams), active master-replica failover, and automatic sharding across 16,384 hash slots. Memcached delivers ultra-simple, multi-threaded key-value caching with low memory fragmentation via slab allocation. This guide details Redis Cluster hash slot sharding, Memcached memory slabs, multi-threading vs single-threading execution models, and cache stampede protection.
Mental Model: Database Load Relief vs Distributed In-Memory Cache Invalidation
In-memory caches sit between application servers and persistent relational databases in a Cache-Aside (Lazy Loading) pattern:
1. Cache Read Hit: Application thread requests key user:1092 from RAM. Returns payload in under 500 microseconds.
2. Cache Read Miss: On cache miss, the application queries PostgreSQL, writes the result to the cache with a Time-To-Live (TTL) expiration, and returns the response. For Redis locking and cache patterns, review prevent cache stampede redis and optimizing database performance redis cache aside.
Quick reference
- In-memory RAM access drops data retrieval latency from 50ms (disk DB) to <1ms.
- Sheds up to 95% of read query load from underlying relational database clusters.
- Cache-Aside pattern ensures application resilience if the cache cluster temporarily fails.
- Enforces TTL expiration policies to prevent stale data accumulation in memory.
- Powers high-throughput caching at Twitter, GitHub, Netflix, Airbnb, and CoreConcept.
Remember this
Implement in-memory caching to shed read query load and achieve sub-millisecond API response times.
Redis Cluster Hash Slots (16,384) & Master-Replica Failover
Redis Cluster shards key-value data across 16,384 logical Hash Slots:
$$\text{slot} = \text{CRC16}(\text{key}) \bmod 16384$$
Every Redis node in the cluster owns a subset of the 16,384 hash slots. Keys containing hash tags (e.g. {user:100}:profile and {user:100}:orders) hash exclusively on user:100, guaranteeing that related keys reside on the exact same cluster node for fast multi-key transactions.
Quick reference
- CRC16 checksum modulo 16,384 distributes keys evenly across master cluster nodes.
- Hash tags ({user_id}) route related keys to identical nodes for atomic multi-key operations.
- Gossip protocol (MEET/PING/PONG) detects node failures and promotes read replicas automatically.
- Scales storage capacity up to terabytes of RAM across hundreds of Redis nodes.
- Delivers transparent client routing via MOVED and ASK cluster redirects.
Remember this
Use Redis Cluster hash tags to group related keys onto identical nodes for multi-key operations.
Memcached Multi-Threaded Slab Allocation vs Redis Single-Threaded Event Loop
Comparing memory management and thread models reveals architectural differences:
- Memcached: Multi-threaded architecture that scales linearly across multiple CPU cores using pthread locks. Allocates memory in fixed-size Slabs (e.g. 64B, 128B, 256B chunks) to prevent OS memory fragmentation and avoid expensive malloc/free heap calls.
- Redis: Single-threaded event loop (ae.c I/O multiplexing via epoll/kqueue) that processes requests sequentially in RAM. Eliminates multi-thread lock contention and context-switching overhead completely.
Quick reference
- Memcached multi-threading leverages all available CPU cores on large multi-core servers.
- Slab allocation in Memcached eliminates OS heap fragmentation during high-frequency overwrites.
- Redis single-threaded event loop executes atomic operations (INCR, HSET, LPUSH) without locks.
- Redis supports persistent RDB snapshots and AOF append-only logs; Memcached is volatile-only.
- Provides optimized memory performance tailored to key-value workload patterns.
Remember this
Deploy Memcached for simple multi-core key-value caching and Redis for complex data structures.
Cache Stampede (Thundering Herd) Protection via Atomic Locks & Probabilistic Early Expiry
When a high-traffic cache key expires (homepage:trending), thousands of concurrent application threads experience a cache miss simultaneously, sending thousands of identical heavy SQL queries to the database (a Cache Stampede).
### Mitigation Strategies
1. Atomic Lock (Mutex): The first thread that misses acquires a Redis lock (SET lock_key uuid NX EX 10), queries the DB, updates the cache, and releases the lock. Subsequent threads wait for the lock or retry.
2. XFetch Probabilistic Early Expiration: Recomputes cache values before expiration based on read frequency and computation cost.
Quick reference
- Distributed locks (SET NX EX) ensure only one thread queries the database on cache miss.
- XFetch probabilistic early expiration algorithm refreshes hot keys before TTL expiration occurs.
- Cache warming pre-populates high-traffic catalog items prior to scheduled marketing spikes.
- Monitors cache hit ratio (keyspace_hits vs keyspace_misses) in Datadog / Grafana.
- Guarantees database stability during peak concurrency spikes.
Remember this
Implement atomic Redis locks or probabilistic early expiry to prevent catastrophic cache stampedes.
Key takeaway
To test Redis Cluster locally, run docker run -d --name redis-cluster -p 7000-7005:7000-7005 grokzen/redis-cluster. Test hash slot routing via redis-cli -c -p 7000 cluster info.
Related Articles
Explore this topic