Understanding Distributed Caching: Use Cases, Memcached vs Redis Comparison, and Common Challenges

Why Use Distributed Cache

In high‑concurrency scenarios such as Taobao’s Double‑11 flash sale, billions of requests can overwhelm databases; adding a cache layer before the database reduces load and improves response time, while a distributed cache avoids the memory waste of duplicated local caches.

Distributed Cache Use Cases

Page caching – storing fragments of web pages (HTML, CSS, images).

Application object caching – second‑level cache for ORM frameworks to relieve database pressure.

Session/state caching – synchronizing session data across distributed web nodes for high‑availability clusters.

Parallel processing – sharing intermediate computation results.

Cloud services – providing distributed cache as a service.

Distributed Cache Comparison: Memcached vs Redis

Redis supports richer data structures (list, set, sorted set, hash) while Memcached only handles simple key/value.

Redis offers persistence (RDB, AOF); Memcached has none, so a crash clears all data.

Both provide clustering: Memcached via client‑side consistent hashing, Redis via server‑side solutions such as Twemproxy, Codis, or Redis Cluster.

Key size limits differ: Memcached keys up to 250 bytes, values up to 1 MB; Redis keys up to 512 KB.

Memcached can use multiple CPU cores; Redis is single‑threaded, giving higher per‑core performance for small data but lower for large payloads.

Memory management: Memcached uses slab allocation; Redis relies on the system malloc/free, which may cause fragmentation.

Distributed Cache Selection Summary

Choose Redis when persistence or complex data structures are required; otherwise both meet performance and stability needs.

Common Problems and Challenges

Cache avalanche : Simultaneous expiration of many keys forces a sudden surge of database traffic, potentially crashing the DB.

Cache penetration : Requests for nonexistent data bypass the cache and repeatedly hit the database.

Cache warm‑up : Pre‑loading frequently accessed data into the cache after deployment to avoid initial DB hits.

Cache update : Strategies include periodic cleaning of expired entries or lazy refresh on each request, each with trade‑offs.

Cache degradation : When traffic spikes or services degrade, degrade non‑essential features while keeping core functionality available, using automatic or manual switches.