← Concepts

阅读中文版本

Distributed Caching

A distributed cache shares cached data across many application instances, giving a single logical cache that survives a single process restart.

caching

Definition

A distributed cache is a cache whose entries are stored on dedicated nodes or partitioned across them, so any application instance can read and write the same logical data set.

Context and scope

It is used when many horizontally scaled instances must serve the same hot data without each holding a divergent copy.

Common misconceptions

  • a distributed cache is automatically consistent across nodes
  • an in-process cache and a distributed cache are interchangeable

Anti-patterns

  • treating a distributed cache as durable storage
  • using it without a fallback when it becomes unavailable

Related concepts

Related examples

Authoritative source

https://redis.io/docs/latest/operate/oss_and_stack/management/scaling/

Definition

A distributed cache is a cache whose entries are stored on dedicated nodes or partitioned across them, so any application instance can read and write the same logical data set.

It is used when many horizontally scaled instances must serve the same hot data without each holding a divergent copy. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Because entries live on remote nodes, every lookup adds a network round trip, which is acceptable for large shared objects but wasteful for tiny hot values.

Partitioning and replication decide what happens when a node fails, and an eviction on one node affects all clients that read that key, unlike a local cache.

Trade-offs and alternatives

Treat the cache as best-effort: a miss or an outage must fall back to the source of truth rather than fail the request. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that a distributed cache is automatically consistent across nodes. Another is that an in-process cache and a distributed cache are interchangeable. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to treating a distributed cache as durable storage and to using it without a fallback when it becomes unavailable. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Write-Behind Caching, Cache Partitioning via Consistent Hashing, Edge Caching at the CDN.