Distributed Cache diagram template
A sharded cache tier with consistent hashing, replicas and a cache-aside application.
About this design
A cache tier is only useful if it is cheaper and faster than what it protects, and only safe if you know what happens when it is cold. Here the application owns the logic: it asks a client library which shard holds a key using consistent hashing, reads from that shard, and on a miss loads from the database and writes the value back with a time to live. Each shard has a replica that is promoted if the primary fails, and a monitor watches hit ratio, evictions and memory. The diagram is a prompt to discuss thundering herds when a hot key expires, request coalescing, negative caching for missing rows, invalidation versus short expiry, and what capacity you need if the cache disappears entirely. A cache that the database cannot survive without is a dependency, not an optimisation.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Distributed cache"
direction LR
service app "Application"
[app x3]
app -> cache redis "Cache shard 1"
app -> cache redis "Cache shard 2"
app -> cache redis "Cache shard 3"
app -[on miss]-> db postgres "Database"
cache-shard-1 -> cache memcached "Replica 1"
monitor prometheus "Hit ratio"
cache-shard-1 -> hit-ratio
