Compare Caches and fast key-value stores

Redis, Dragonfly, Memcached, Hazelcast or Aerospike: what should hold the data, and what can it safely promise?

Serve frequently read data from a fast store: a rebuildable product copy, or the authoritative session record. Compare the data model, freshness and failure behavior before choosing where the data lives.

The decision underneath: Choose the data model and update operations, then decide which reads may use old copies and what happens when the store is unavailable.

Why this family exists

The problem

The product database answers every kettle page read from disk and its own memory. At 50,000 reads a second it is the slowest and busiest part of the shop, and every other query waits behind those reads.

Without it

Without a cache, every one of Emma's page views is a database read. A database that can serve 5,000 reads a second gets 50,000. Queues build, checkout slows down too, and adding database servers costs far more than adding memory.

What it adds

A cache keeps a copy of the record in memory, where a read takes under a millisecond. The database stays the owner of the truth. The copy may be a little old, and the application decides how old is acceptable. Some products here can also be the only copy, such as a login session. Then database rules apply.

When engineers reach for it

The same rows are read thousands of times a second and the database is the limit.
A read must come back in a millisecond or two, faster than a database round trip.
Many servers must share small, fast-changing records: sessions, counters, a cart.

Drawings are wider than a phone. Drag one sideways, or tap the diagram to open it full screen.

The shop. An online shop that sells kitchen goods. This is the shared starting point; any separate workload is introduced under “On this page too”.
Emma. A customer, customer#42 in the database. Emma buys the kettle.
The kettle. Product 8812, $45. The product in most examples.
Order 881. Emma's order: the kettle plus two more things. Each product in an order is one line.
Jake. A second customer, on the other coast. Jake shows up when two people act at the same second.
Customer#9, the reseller. A business that buys from the shop in bulk and sells the goods in its own store. Examples may give this customer 60 percent of orders or one 10,000-line order. Those are illustrative workloads; the card or scenario states its actual numbers.

Also on every page

Sale day. The day the shop runs a sale. Traffic is many times a normal day, so every limit on the page gets tested that day.
The source of truth. The authoritative record for the operation being discussed, such as product price or order status. A cache, search index or report may hold a copy with different freshness guarantees.
Retries and request IDs. A timeout does not prove an operation failed. A retry repeats the attempt; a stable request or event ID lets the system recognize the same operation and check its recorded outcome.

On this page too

The page service. The code that builds the kettle page. It serves 50,000 product-page reads a second across the catalogue. Product 8812 is Emma’s example.
Sessions. Emma's login token, 'token abc = Emma'. The cache is the only place sessions are kept, and every API request looks one up.
The sale countdown. One key, 'sale:today', that every page reads during the live sale. 80,000 reads a second land on that one key.
Product copies and prices. The product database owns the catalogue record. The page service caches a copy; examples distinguish an old displayed price from the price accepted at checkout.
The two carts. cart:42 is Emma’s cart and cart:77 is Jake’s. Moving an item between them is the multi-key example: both changes must happen, or neither.
Session revocation. After logout succeeds, every gateway must reject the old token. The session scenario adds automatic login renewal using a separate credential.

The shapes in this family

4 ways to hold the copy. The drawing shows which product sits on which branch. The lines under it say what each branch means for a read.

A copy inside the process
The copy lives in the page service's own memory. A read costs no network trip. Every process has its own copy, so a price change reaches them one by one.
A shared in-memory server
One server, or a few, hold the copies in memory. Every read is one network trip. Every page service sees the same copy.
An in-memory data grid
A cluster of processes that each own a slice of the data, keep a backup of the slice on another process, and can run your code where the data is. It can also live inside a Java application.
A record store with an index in memory and records on SSD
A cluster that can hold more data than memory, used as a cache or as the only copy. It also belongs to the distributed key-value family.

Where they overlap: Redis and Dragonfly share the commands and the data types, and differ in threading and command coverage. Memcached and Redis both hold rebuildable copies. Hazelcast and Aerospike both keep a copy on another server before saying OK, and both can be the only copy of a record.

Named, not scored: Valkey. A fork of Redis 7.2 under a BSD licence, run by the Linux Foundation. Same build and commands, so compare it as Redis here. · Caffeine, or a plain map. A cache library inside a Java or Go process. No server at all. The first thing to try when one process's memory is enough. · A CDN. Caches whole pages and images near the user. It isn't a store the application reads by key. · Database read replicas. Extra copies of the database for reads. As slow as the database, so not a cache, but often enough.

Redis
Use in-memory hashes, sets and other typed values
Your servers, or a managed service · A shared in-memory server
Redis keeps typed values such as hashes, lists and sets in memory. Ordinary commands execute serially on the main command thread; I/O and background work may use other threads. Replication and persistence are configurable.
For example
The page service handles 50,000 product reads a second across the catalogue; Emma asks for product 8812.
Dragonfly
Serve Redis-compatible types across worker cores
Your servers, or a managed service · A shared in-memory server
Dragonfly speaks the Redis wire language, and the Memcached one if you turn it on. Not every Redis command exists, so check the list. Inside, each thread owns a slice of the keys.
A command that touches several slices makes those threads coordinate.
For example
The shop can test whether one multi-core Dragonfly node handles its product workload. Verify the commands and client behavior used by the application.
Memcached
Keep byte values with simple conditional updates
Your servers, or a managed service · A shared in-memory server
Memcached keeps byte values in memory, with counters and a compare-and-swap update. Several worker threads answer at once. No other server holds a copy of an item. Extstore can put large values on flash for more room, not for safety.
For example
Product pages cache the rendered product JSON and rebuild it from the database on a miss.
Hazelcast
Share distributed collections and run code on entries
Inside your process, or a separate cluster · An in-memory data grid
Hazelcast is a cluster of Java processes, called members, that share maps and other collections. It can run inside your Java application or as its own cluster. Each entry has one owning member and a backup on another.
A client can keep a local copy, called a Near Cache, which can be a moment old.
For example
A Java page service keeps product 8812 in its own memory, with a backup on a second member.
Aerospike
Update typed fields within a record; choose memory or SSD storage
Your servers, or a managed service · A record store with an index in memory and records on SSD
Aerospike stores records made of typed fields called bins, including lists and maps. One operation can update several bins within a record atomically.
It can hold authoritative data or cache copies; the architecture below illustrates a DRAM index with SSD-backed records.
For example
Product 8812 can hold price, views and tags as bins. Update its view count without replacing the whole record; SSD-backed storage is a separate capacity choice.

Questions to ask first

Each answer points at some products and away from others. Those marked ‘can wait’ are secondary questions.

How old may a cached value be, in seconds? Does the answer differ by field?
A TTL says how long a copy may stay in the cache. It does not say how old the data was when it arrived. A slow database read can put an old price back after a newer one was written. So decide two things: how many seconds old a copy may be, and whether some fields, such as the price, must always be current.
What it changes: Invalidation and read-after-write: which copy can still answer old.
Points to: Old by a few seconds is fine: any product, with a TTL. Must be current: the database owns that field, or the page checks a version. No cache product promises it alone.
What happens to the database if every cached value disappears at the same moment?
If the cache restarts empty, every read becomes a database read. A replica that already holds the copies, or a snapshot file loaded at start, shrinks the gap. Neither stops a thousand requests for the same missing key from reaching the database at once. The page service must combine those into one read, and stop sending reads when the database budget is used up.
What it changes: Durability of the copies, and the refill path on a miss.
Points to: Copies survive one member restarting on Hazelcast (a backup on another member), and a whole-cluster restart only with Enterprise persistence. On Aerospike they survive both (SSD and a replica). Redis and Dragonfly need persistence or a replica for that. Memcached refills from the database every time.
Does any operation change several keys at once, where a half-done change would be wrong?
Moving the kettle from Emma's cart to Jake's touches two keys. Ask three things. Can another command slip in between the two changes? Does an error undo the first change? Can a reader see the kettle in neither cart, or in both? A product can say yes to the first and no to the other two.
What it changes: Multi-key atomicity and where the keys must sit: one hash slot, one node, one namespace.
Points to: Yes: Redis or Dragonfly on one server, Hazelcast, or Aerospike Enterprise. No: Memcached stays in the running.
Does one key get most of the traffic?
The countdown key lives on one server, and adding servers for other keys does not help it. Copies on replicas or inside the page service can take the reads, if a copy a moment old is fine. Every write still goes to the one owner. Splitting a counter into several keys spreads the writes, but then no single key holds the true total.
What it changes: Replicas that serve reads, and local copies inside the page service.
Points to: Read-heavy countdown: local copies may fit. Login checks: an old “token valid” copy must not allow access after logout. Check the hot key separately from total throughput.
How big is one value, and how many GB is the data you'll actually read?
Decides whether memory (DRAM) is affordable or an SSD-backed store makes more sense. It also decides one big server versus a cluster of servers.
What it changes: Memory versus SSD, and one node versus a cluster.
Points to: Measure RAM plus overhead and copies for every candidate. As capacity grows, compare SSD-backed options such as Aerospike.
can wait
Which language runtime does the application use?
Only matters if you're thinking about a cache that lives inside the application process, or right next to it. Hazelcast's embedded mode is Java only.
What it changes: Placement: a copy inside the process, or a shared server.
Points to: Java: Hazelcast can live inside the process. Anything else: a shared server, and Hazelcast only as a separate cluster.
can wait

When you don't need any of these

The database already answers the read fast enough, and its read copies (replicas) have spare capacity. A cache would add a second copy you now have to keep in step with the first, for a gain you haven't measured.
The value changes almost every time it's read (a live account balance, a lock). You'd throw the cached copy away as often as you filled it.
The hot data fits in the application's own memory, and a copy that's one minute old is fine. A plain map inside the process needs no new server at all. Each entry in it is dropped after a set time, called a TTL (time to live).

The life of one copy

One trip through the cache, from the read to the moment the copy leaves. Every product here does these six steps. The links under the drawing go to where they differ.

Read. The page service asks the cache for product:8812, one trip to a shared server or none to a local copy. where they differ
Hit or miss. A hit returns the copy. A miss means no copy: it was never filled, it expired, or it was pushed out for space. where they differ
Source read. On a miss the page service reads the database. A thousand misses for the same product must become one database read. where they differ
Fill. The page service writes the copy back with a lifetime. The server says OK. What that OK survives differs per product. where they differ
Expire, evict or invalidate. The copy leaves by timing out, by being pushed out when memory is full, or when the code that changed the price deletes it. where they differ
Read after a write. A write in the database and a delete in the cache are two steps. A slow fill can put the old price back between them. where they differ

5 cards

Five problems, drawn for each product

Each card starts with one problem from the shop. Then you see how each product handles that same problem. Tap any drawing to open it full screen.

Card 1 of 5

Where does the copy of product 8812 live?

The shop caches popular products to reduce database reads. A shared cache hit crosses the network. A local hit avoids that trip, but each process now holds a copy that can become stale.

How each product handles it

Redis: shared server with optional tracked client copies page service 1 trip Redis server copy of 8812 local copy of 8812 "8812 changed, drop yours" Tracked copies: discard if invalidation delivery is lost.
Watch out
But Your client library has to support this feature, and not all of them do.
If the connection that carries the 'it changed' messages drops, throw away the whole local copy, because you can no longer trust it.
Redis
Redis is a separate server, so each read is one trip.
- Redis can also tell the page service: keep your own copy of 8812, and I'll message you when it changes.
- That feature is called client-side caching.
- With it, most reads make no trip at all.
Dragonfly: Redis protocol, command-specific compatibility page service 1 trip Dragonfly server copy of 8812 local copy of 8812 "8812 changed" (basic mode) Basic tracking only; check client-mode compatibility.
Watch out
But These options concern broadcast/prefix invalidations and redirecting notifications to another connection. Check your client’s tracking mode and discard untrusted local copies after a notification connection failure.
Dragonfly
Dragonfly accepts Redis clients for supported commands.
- Basic client tracking is available, but BCAST, PREFIX and REDIRECT are not supported in the current compatibility list.
Memcached: separate servers that know nothing of each other page service 1 trip memcached 1 8812 lives here memcached 2 the page service works out which server from the key your own local copy? No automatic invalidation of this local copy.
Memcached
Memcached is a group of separate servers that don't know about each other.
- The page service works out which server holds 8812 from the key, then makes one trip.
- If you want a local copy, you build it yourself.
- Memcached will never tell you when it goes stale.
Hazelcast: can live inside the page service itself page service (Java process) Hazelcast member copy of 8812 in the same memory 0 trips for this locally owned entry second member backup copy kept in sync Local ownership shown. Remote entries still require a trip.
Watch out
But A Near Cache copy can be up to 10 seconds old, because invalidations travel in batches. The docs call that eventually consistent.
A successful write does not mean every client has invalidated its old copy; do not use that path alone for strict revocation checks.
Hazelcast
Hazelcast can embed a member in a Java application.
- A locally owned entry needs no network trip; other entries still go to their owner.
- An optional Near Cache serves local copies in supported clients, but change notifications take time to arrive, so it can briefly return an old value.
Aerospike: a separate cluster, index in memory, data on SSD page service 1 trip memory: where is 8812? SSD: the record itself Recent records may be read from memory buffers.
Watch out
But Aerospike can also keep records in memory. The storage you pick does not change the record and bin model. One network trip plus one SSD read is the usual cost of a read.
Aerospike
Aerospike stores records with typed bins.
- The illustrated storage mode keeps an index in DRAM and records on SSD; recent records may be read from memory buffers.
- Bins describe the record.
- Memory or SSD is where it sits.

Remember: Local hits avoid a network trip. They also introduce another copy whose freshness the application must account for.

Card 2 of 5

50,000 reads a second arrive. Who does the work inside the server?

The cache server has 8 CPU cores. 50,000 reads a second come in, plus the odd slow command, like 'list every key'. How the server hands work to its cores decides two things.

How many reads a second one server can do. And whether one slow command makes everyone else wait.

How each product handles it

Redis: ordinary commands share one main thread 50,000 reads/s Redis server main thread: ordinary commands other threads: configured I/O background work: persistence, freeing extra cores do not split this path A slow command delays this main command thread.
Redis
Redis executes ordinary commands serially on its main command thread.
- I/O and background work can use other threads.
- A slow command delays other commands on that instance; adding cores does not automatically parallelize that command path.
Dragonfly: each core owns a slice of the keys 50,000 reads/s Dragonfly server worker 0: hashed keys (8812 here) worker 1: other hashed keys worker 2: other hashed keys worker 3: other hashed keys Multi-key operations may coordinate several workers.
Watch out
But How much work it can handle per second grows with the number of cores on one node. That's controlled by the proactor_threads setting, one per core by default.
But a single key is still served by just one thread.
Dragonfly
Dragonfly assigns keys to worker shards across cores.
- A single-key operation runs on its owning worker.
- Multi-key operations can coordinate several workers, so a slow operation is not always confined to one shard.
Memcached: worker threads share one item table with tiny locks 50,000 reads/s memcached server worker 1 worker 2 worker 3 worker 4 item table (8812, 8813, ...) locks cover hash-bucket ranges Different keys can contend on a shared bucket-range lock.
Watch out
But The docs advise against setting the number of worker threads (the -t flag) far above the number of CPU cores.
Memcached
Memcached workers share the item table and lock hash-bucket ranges while accessing items.
- Different keys can run concurrently, but may contend on a shared lock; there is not a dedicated lock for every item.
Hazelcast: 271 partitions, each owned by one thread 50,000 reads/s Hazelcast member thread 1: partitions 0-67 thread 2: partitions 68-135 (8812 here) thread 3: partitions 136-203 thread 4: partitions 204-270 MapStore I/O: offloaded by default in 5.5.
Hazelcast
Hazelcast maps partitions to operation threads; several partitions can share a thread.
- Commands on that thread run serially.
- A database call from the map does not sit on that thread: it is handed to a separate pool.
Aerospike: many service threads, but one record is handled in order 50,000 reads/s Aerospike node service thread service thread service thread service thread Changes to the same record serialize.
Aerospike
Aerospike uses many service threads.
- Two changes to the same record are done one after the other on the computer that owns it.
- Different records run in parallel.

Remember: A slow command blocks its lane. With one lane, it blocks everyone.

Card 3 of 5

The server said 'saved'. Is Emma's session safe?

Emma’s session has no backing database. When the server replies saved, ask which copies acknowledged it and what a crash can still lose. A lost login forces another login; a lost revocation can restore access.

How each product handles it

Redis: ordinary replies do not wait for replica acknowledgement login service main server backup 1 2 3 1 save 2 reply 3 replicate One possible ordering: a crash before 3 loses this write.
Redis
It depends.Redis replication is asynchronous: an ordinary write reply does not wait for a replica acknowledgement.
- AOF persistence and WAIT reduce loss exposure, but do not make every failover loss-free.
- They do not by themselves prove permanent session revocation.
Dragonfly: asynchronous replication can lose recent writes login service main server backup 1 2 3 1 save 2 reply 3 replicate One possible ordering: a crash before 3 loses this write.
Watch out
But The replication page doesn't say how much data you could lose in a failover, the moment a backup server takes over. WAIT is listed as fully supported.
Still, test what it actually does on your version before you rely on it.
Dragonfly
It depends.Same as Redis: replication is asynchronous, so a promoted replica can miss the last acknowledged write.
- The difference is the recovery point: snapshots taken at a point in time, no append-only log.
Memcached: volatile mode, no built-in replica login service the only server 1 2 1 save 2 reply no replica Illustrated volatile mode: a crash loses the session. no copy
Memcachednot supported
No.The default volatile Memcached server has no replicated backup.
- A crash loses its sessions.
- Planned warm restart can retain items on the same host under its documented conditions; extstore adds capacity, not crash durability.
Hazelcast: copies to the backup first, then says 'saved' login service main server backup 1 2 3 1 save 2 sync backup 3 reply Successful path shown; timeout outcomes require handling.
Hazelcast
It depends.With a synchronous IMap backup configured, completion normally waits for backup acknowledgement.
- That backup alone does not ensure every gateway sees logout during a failure.
- After a member restarts, can a gateway read Emma's old session from a Near Cache?
- Yes, until its TTL.
Aerospike: RF 2, COMMIT_ALL; device flush is separate login service main server backup 1 2 3 SSD (4, later) 1 save 2 replica accepts 3 reply 4 device flush Normal buffering shown; replica acceptance is not disk flush.
Watch out
But Data reaches the SSD in chunks called write blocks. So getting an OK back doesn't mean the bytes are actually on disk yet.
Turning on the commit-to-device setting in SC mode forces the write to reach disk before the OK.
The SC exceptions include clock skew, meaning a difference of more than 27 seconds between two servers' clocks, and repeated unclean shutdowns.
Aerospike
Yes.With replication factor 2 and COMMIT_ALL, the illustrated write waits for a replica before success; device flush may happen later.
- That covers one node dying.
- A split, or a restart that brings old records back, is a separate question, answered in the sessions scenario.
- OK means a replica has the logout.
- An AP replica read can still say the session is valid for a moment.

Remember: If the cache is the only copy of something, this card is a hard requirement, not a tuning knob.

Card 4 of 5

One key is read 80,000 times a second. Where does the load land?

The sale countdown gets 80,000 reads/sec for one key. Adding servers for other keys does not automatically share this load. Local copies or replicas may help this read if some staleness is allowed.

For a login check, an old local answer saying “token valid” could allow a request after logout.

How each product handles it

Redis: spread reads with replicas or client copies. Writes stay put. 80,000 reads/s main server one core owns 'sale:today' replica: reads replica: reads client copies (client-side caching) Copied values may be stale; writes go to the primary. replica reads (may lag)
Watch out
But Redis Cluster replica reads require READONLY on the replica connection. Check that the client routes those reads as intended.
Redis
The key sits on one Redis server and runs on its single command core.
- To spread reads, add read-only replica servers, extra copies of the data that only serve reads, and let clients read from them.
- Or let clients keep their own copy.
- Writes to the key still all go to the one server.
Dragonfly: one core gets the key, but the other cores keep working 80,000 reads/s Dragonfly server core 0: 'sale:today', 100% busy core 1: other keys, fine core 2: other keys, fine core 3: other keys, fine Illustrated single-key path; cross-shard work can involve others.
Dragonfly
One core of one Dragonfly server owns the key, and the other cores keep serving everything else.
- But that key gets one core's worth of reads and no more.
Memcached: one server, no replica reads 80,000 reads/s server 1 'sale:today' 100% busy server 2 idle Optional proxy fan-out creates separate copies; not built-in replicas.
Watch out
But There's no way to read from a backup copy here. A routing tool such as mcrouter, or the built-in proxy, can copy one key across several groups of servers instead.
Memcached
One Memcached server owns the key, and there are no replica reads to spread it.
- A proxy can write the key to several servers so clients spread out, but you set that up yourself.
Hazelcast: each client keeps the value in its own near cache 80,000 reads/s client 1 near cache client 2 near cache client 3 near cache Near Cache hits stay local owner of 'sale:today' "it changed" only, to each client Invalidations may lag; misses and writes reach the owner.
Hazelcast
An enabled Near Cache serves hits locally; misses still contact the owner.
- The owner sends asynchronous invalidations after changes, so a client may briefly use an old countdown.
- For login checks, that delay could keep allowing requests after logout.
Aerospike: in AP mode (available over in sync), copies can answer reads 80,000 reads/s master computer 'sale:today' replica: reads replica: reads AP replica reads may return an older value. replica reads (may lag)
Watch out
But AP replica reads may return old values. SC offers different read policies; select and verify a linearizable key-read path for strict revocation. A replica count does not establish that read contract.
Aerospike
The master computer for the key takes every write.
- But in AP mode, the mode that favors staying available over always being perfectly in sync, replica computers can take the reads.
- Those copies can be a moment old.

Remember: Copies can spread reads when their freshness is acceptable. Splitting writes across several keys changes the operation and its consistency requirements.

Card 5 of 5

Move the kettle from Emma's cart to Jake's. Can the cache change both keys together?

Moving the kettle between cart:42 and cart:77 changes two keys. Ask whether another command can interleave, whether an error rolls back earlier changes, and whether a reader can see half the move. Those are three separate promises.

Sending both changes in one request gives you none of them by itself.

How each product handles it

Redis: one server; in Cluster, keys must share a hash slot. one server cart:42 cart:77 MULTI or Lua: both together cluster: keys spread over servers cart:42 server A cart:77 server C refused Same hash slot required in Cluster. Runtime errors do not roll back. Example tag: {shop1}cart:42 and {shop1}cart:77
Redis
It depends.MULTI/EXEC or Lua can execute both changes without other client commands interleaving.
- Cluster keys must share a hash slot, for example using one hash tag.
- Runtime errors do not roll back earlier successful changes: validate before modifying data.
Dragonfly: yes across the cores of one server one Dragonfly server core 0: cart:42 core 2: cart:77 one transaction This boundary covers one server, not independent cluster owners.
Watch out
But Within one server, keys may be on different worker shards. The cluster documentation describes slot ownership and hash tags; do not infer a distributed transaction across independent owners.
Scope this example to one server and verify cluster command restrictions for the deployed version.
Dragonfly
Yes.One Dragonfly server coordinates a transaction across the worker shards that own the keys.
- This drawing does not establish transactions across independent cluster owners.
- Check deployed cluster command restrictions; worker shards are not cluster nodes.
Memcached: no. Two commands, two keys, no link cart service server 1: set cart:42 server 2: set cart:77 a crash between the two leaves the kettle half-moved
Memcachednot supported
No.Memcached can't.
- Each mutation changes one key independently.
- A crash between the two commands leaves the kettle half-moved.
- Keep carts in the database instead.
Hazelcast: yes, a transaction across partitions and servers member 1 cart:42 (partition 7) member 2 cart:77 (partition 200) transactional map: commit both Nontransactional readers may see a partial cross- partition commit.
Watch out
But Locks used for writing are held until the change is made final, so keep transactions short. If a member dies or the cluster splits mid-move, the kettle can end in both carts or in neither.
That's when the cluster splits into two halves that each think they're the whole cluster.
Hazelcast
It depends.Transactional maps coordinate changes across members, but a reader outside the transaction can briefly see the kettle removed from Emma’s cart before it appears in Jake’s.
- TWO_PHASE copies a commit log so a surviving member can finish a commit; it does not make every reader’s view isolated.
Aerospike 8: yes, but only in strong-consistency mode (paid edition) computer 1 record cart:42 computer 2 record cart:77 transaction: needs an SC namespace (Enterprise) Community Edition: atomic updates within one record only.
Watch out
But A transaction can write up to 4096 records. Any delete inside a transaction should be marked as a durable delete. That's a delete that's tracked so it can't accidentally come back later.
The Community Edition has no strong-consistency mode, so it has no transactions across several records.
Aerospike
It depends.Aerospike 8 can change several records together, but only inside a namespace, a named group of records, that's set to strong consistency.
- That mode needs the paid edition.
- Inside one record, changing several fields at once is always atomic.

Remember: Choose the transaction and read guarantees the operation needs. MULTI stops other commands slipping in. It does not undo change one if change two fails, and it does not survive a crash.

5 products

How each one is built

One drawing of the machine per product, with its explanation under it. Then follow the numbered request and response flow in our shop. Full details adds request-flow internals and sources.

Redis
Redis Open Source 8.x · one primary and one async replica shown · optional RDB/AOF · cache-aside with 60 s TTL
Redis · serial commands, shared memory. Redis Open Source 8.x · one primary and one async replica shown · optional RDB/AOF · cache-aside with 60 s TTL. GET product:8812 reaches the primary. Network I/O can use I/O threads; the main thread looks up the live key in memory and returns its value or a miss. SET updates the in-memory value and expiry on the main thread. Ordinary OK does not wait for a durable replica or a per-write disk flush. AOF fsync policy and RDB snapshots determine persistence separately. Command execution is mainly serial, while network I/O and background work can use other cores. A slow command still delays subsequent commands on the same primary.
A single command execution thread makes operations such as a Lua script or an EXEC command sequence run without interleaving other clients’ commands. Atomic execution does not mean rollback or guaranteed durability.
Shape. One process with in-memory key dictionaries. A main thread executes ordinary commands sequentially; configured I/O threads and background tasks handle other work.
- GET product:8812 reaches the primary. Network I/O can use I/O threads; the main thread looks up the live key in memory and returns its value or a miss.
- SET updates the in-memory value and expiry on the main thread. Ordinary OK does not wait for a durable replica or a per-write disk flush. AOF fsync policy and RDB snapshots determine persistence separately.
- Command execution is mainly serial, while network I/O and background work can use other cores. A slow command still delays subsequent commands on the same primary.
Compute
1 main thread for commands, I/O threads for sockets
Data lives in
memory, key dictionaries and value objects
Durability
optional RDB snapshots and AOF; fsync policy sets the loss window
Copies
replicas, asynchronous
Scale out
Redis Cluster: 16,384 hash slots across primaries
- What limits it, and what the copies and the disk are for, are in Full details.
In our shop. The read, the miss, the fill and the later price change follow the shared cache-aside path exactly, drawn once in the life of one copy. What differs for Redis is above: where the key lives, who runs the command, and what OK means.
Dragonfly
Dragonfly 1.x · self-hosted primary and replica · in-memory shard-per-thread model · optional snapshots
Dragonfly · each thread owns its keys. Dragonfly 1.x · self-hosted primary and replica · in-memory shard-per-thread model · optional snapshots. The server routes GET product:8812 to the shard thread owning that key. That thread looks up its own in-memory dashtable, the key-to-value lookup structure, and returns the value or a miss. A single-key SET updates the owning shard. Multi-key operations can span shard threads and use the transactional scheduler, so their work requires coordination. Shard threads use multiple cores inside one process. Independent single-key work can proceed on other shards; this does not eliminate shared resource limits or cross-shard coordination.
It spreads keys across threads within one process, using multiple cores without requiring a separate Redis process for each shard. Whether it replaces several servers depends on the workload.
Shape. One process with one thread per core. Each thread owns a slice of the keys, called a shard. It runs its own event loop (the loop that takes requests in turn), so threads share nothing.
- The server routes GET product:8812 to the shard thread owning that key. That thread looks up its own in-memory dashtable, the key-to-value lookup structure, and returns the value or a miss.
- A single-key SET updates the owning shard. Multi-key operations can span shard threads and use the transactional scheduler, so their work requires coordination.
- Shard threads use multiple cores inside one process. Independent single-key work can proceed on other shards; this does not eliminate shared resource limits or cross-shard coordination.
Compute
one thread per core, each owning a shard
Data lives in
memory, one dashtable per shard
Durability
snapshots, written per shard in parallel
Copies
replicas, asynchronous
Scale out
a bigger machine first, cluster mode as documented
- What limits it, and what the copies and the disk are for, are in Full details.
In our shop. Same shared path as Redis: the cache-aside steps drawn once in the life of one copy. What differs for Dragonfly is in the drawing and bullets above.
Memcached
Memcached 1.6.x · direct client hashing · volatile servers · proxy, extstore and warm restart excluded from the illustrated path
Memcached · independent servers, shared table. Memcached 1.6.x · direct client hashing · volatile servers · proxy, extstore and warm restart excluded from the illustrated path. get product:8812 is handled by one worker thread. It hashes the key, takes a lock on that part of the table, reads the item and answers. The client library chose this server by hashing the key, since servers never talk to each other. set stores the bytes in a slab chunk of the smallest size class that fits. When memory is full the least recently used item in that class is dropped. Nothing goes to disk and no other server gets a copy. Four worker threads by default, more by a flag. Reads scale across cores because each worker locks only the hash-bucket range it needs, not one big lock.
The client selects a server, and that server stores opaque values independently. The default deployment has no replication; a lost cache must be refilled from the source.
Shape. One process with a fixed pool of worker threads that share one hash table, and a slab allocator that hands out memory in size classes.
- get product:8812 is handled by one worker thread. It hashes the key, takes a lock on that part of the table, reads the item and answers. The client library chose this server by hashing the key, since servers never talk to each other.
- set stores the bytes in a slab chunk of the smallest size class that fits. When memory is full the least recently used item in that class is dropped. Nothing goes to disk and no other server gets a copy.
- Four worker threads by default, more by a flag. Reads scale across cores because each worker locks only the hash-bucket range it needs, not one big lock.
Compute
4 worker threads by default, one shared table
Data lives in
memory, shared hash table and size-class slabs; extstore optional
Durability
none in this volatile configuration
Copies
none
Scale out
the client hashes keys across servers
- What limits it, and what the copies and the disk are for, are in Full details.
In our shop. Same shared path as Redis: the cache-aside steps drawn once in the life of one copy. What differs for Memcached is in the drawing and bullets above.
Hazelcast
Hazelcast 5.5 · client/server IMap · one synchronous backup · custom MapLoader/MapStore, write-delay-seconds=0 · Near Cache off in this flow · smart-client backup acknowledgements enabled
Hazelcast · partition owners and backups. Hazelcast 5.5 · client/server IMap · one synchronous backup · custom MapLoader/MapStore, write-delay-seconds=0 · Near Cache off in this flow · smart-client backup acknowledgements enabled. A smart client sends map.get to the partition owner. A hit returns from the map; a miss can invoke the configured MapLoader. An optional Near Cache serves local hits, but may hold stale data. In this write-through example, map.set invokes the configured MapStore and updates the distributed map. One synchronous backup is configured. Database completion, backup state and near-cache invalidation are distinct. Partition operations are assigned to partition threads. MapLoader/MapStore calls are offloaded to an executor by default in 5.5, so external database I/O need not occupy a partition thread.
The map can load missing values and write changes through a configured database integration. Embedded mode or a Near Cache can avoid network trips for local data; remote partitions still require them.
Shape. A cluster of Java processes, called members, divides map data into 271 partitions by default. Each partition has an owner and configured backups on other members.
- A smart client sends map.get to the partition owner. A hit returns from the map; a miss can invoke the configured MapLoader. An optional Near Cache serves local hits, but may hold stale data.
- In this write-through example, map.set invokes the configured MapStore and updates the distributed map. One synchronous backup is configured. Database completion, backup state and near-cache invalidation are distinct.
- Partition operations are assigned to partition threads. MapLoader/MapStore calls are offloaded to an executor by default in 5.5, so external database I/O need not occupy a partition thread.
Compute
partition threads inside each member, a JVM
Data lives in
JVM heap, 271 partitions by default; partition 17 is illustrative
Durability
map and backup in memory; external database via MapStore
Copies
one backup per partition, synchronous by default
Scale out
add members, partitions move to them
- What limits it, and what the copies and the disk are for, are in Full details.
In our shop: read-through and write-through for product 8812
Hazelcast · follow one product. Hazelcast 5.5 · client/server IMap · one synchronous backup · custom MapLoader/MapStore, write-delay-seconds=0 · Near Cache off in this flow · smart-client backup acknowledgements enabled. 1 Read through the map: The smart client routes to the product partition owner. 2 Load on a miss: The owner invokes the configured loader to read the database. 3 Loaded value: The loader returns the product for storage in the map. 4 Read response: The owner returns the product to the page service. 5 Later: update the map: The shop sends the new product to the partition owner. 6 Write through: The configured store writes the change to the database. 7 Store completes: The database commit completes and the store method returns. 8 Replicate map entry: The owner copies the updated entry to its backup member. 9 Owner responds: The owner returns its result and the required backup count. 10 Backup confirms to client: The backup acknowledges directly to the smart client, allowing the call to complete.
Steps 1 to 4: the shared path
Read, miss, source read, fill. The same for every product here, drawn once in the life of one copy. The numbers in the drawing match.
Later: update the map
The shop sends the new product to the partition owner.
Write through
The configured store writes the change to the database.
Store completes
The database commit completes and the store method returns.
Replicate map entry
The owner copies the updated entry to its backup member.
Owner responds
The owner returns its result and the required backup count.
Backup confirms to client
The backup acknowledges directly to the smart client, allowing the call to complete.
Watch out. Write-through is not one atomic transaction with every copy. Near Cache, if enabled, may return stale data.
Aerospike
Aerospike Database 8.x · AP namespace · index in DRAM, records on SSD · example replication factor 2, COMMIT_ALL, normal write buffering
Aerospike · memory index, buffered SSD storage. Aerospike Database 8.x · AP namespace · index in DRAM, records on SSD · example replication factor 2, COMMIT_ALL, normal write buffering. The client maps the key to one of 4,096 partitions per namespace and sends it to the master in this example. The in-memory index points to the record, which may be in a recent write buffer/cache or read from SSD. The master updates the record through a write buffer and replicates it. With COMMIT_ALL it waits for replica acceptance. Normal buffering can return success before a device flush; commit-to-device changes that condition. Service threads handle requests, with storage I/O and background maintenance alongside them. Throughput depends on CPU, memory, device I/O and workload, not SSD count alone.
With the index in DRAM and records on SSD, data capacity can exceed memory. Recent records can be read from buffers/cache, while other lookups require device I/O.
Shape. One process per node. The primary index lives in memory, 64 bytes per record, and the records live on SSD. Data is a flexible hierarchy with no fixed schema. A namespace, which picks the storage engine, holds sets. A set holds records, and a record holds bins, its named fields, which can differ between records.
- The client maps the key to one of 4,096 partitions per namespace and sends it to the master in this example. The in-memory index points to the record, which may be in a recent write buffer/cache or read from SSD.
- The master updates the record through a write buffer and replicates it. With COMMIT_ALL it waits for replica acceptance. Normal buffering can return success before a device flush; commit-to-device changes that condition.
- Service threads handle requests, with storage I/O and background maintenance alongside them. Throughput depends on CPU, memory, device I/O and workload, not SSD count alone.
Compute
service threads plus I/O threads per node
Data lives in
index in memory at 64 B per record, records on SSD. namespace > set > record > bins, schemaless
Durability
SSD-backed, writes buffered before the device
Copies
example RF 2; COMMIT_ALL waits for replicas
Scale out
4,096 partitions spread over the nodes
- What limits it, and what the copies and the disk are for, are in Full details.
In our shop: product 8812 lives in Aerospike
Aerospike · follow one product. Aerospike Database 8.x · AP namespace · index in DRAM, records on SSD · example replication factor 2, COMMIT_ALL, normal write buffering. 1 Route the read: The partition-aware client sends the read to the master. 2 Return the record: The node looks up the memory index and returns the record. 3 Later: write the product: The update handler writes directly to the partition master. 4 Replicate the write: The master sends the record to the partition replica. 5 Replica accepts: The replica acknowledges the write under its storage configuration. 6 Write result: The master returns success after the configured replica work.
Steps 1 to 2: the shared path
Read, miss, source read, fill. The same for every product here, drawn once in the life of one copy. The numbers in the drawing match.
Later: write the product
The update handler writes directly to the partition master.
Replicate the write
The master sends the record to the partition replica.
Replica accepts
The replica acknowledges the write under its storage configuration.
Write result
The master returns success after the configured replica work.
Watch out. COMMIT_ALL is replica acknowledgement, not a per-write SSD flush or an AP-mode strong-consistency guarantee.

5 cases

When it fails

One failure at a time. For every product: what failed, what happens inside, what the page service sees, what survives, what is lost, and how it recovers.

Failure 1 of 5

One of the two cache servers restarts with empty memory

Redis
The Redis primary process restarts.
Inside
Memory is empty. With RDB or AOF on, it loads the last snapshot or replays the log before serving.
The page service sees
Misses for every product until the cache refills, or a wait while the file loads.
What survives
Everything written before the last snapshot or fsync, if persistence is on.
What is lost
Writes after the last snapshot, or the last second with fsync every second. Everything, with persistence off.
Recovery
Refill from the database inside the 5,000 reads a second budget, or load the file and accept the gap.
Dragonfly
The Dragonfly process restarts.
Inside
Each shard thread loads its own snapshot file, if snapshots are on.
The page service sees
Misses until the shards are loaded and the rest is refilled.
What survives
The last snapshot, one file per shard.
What is lost
Everything since the last snapshot. There is no append-only log in the version we checked.
Recovery
Load the snapshots, then refill the rest from the database.
Memcached
One Memcached server restarts.
Inside
Memory is empty. The other servers know nothing about it and keep serving their own keys.
The page service sees
Misses for the keys that hashed to this server, about one fifth of reads with five servers.
What survives
The keys on the other servers.
What is lost
Every item on this server. A planned restart with warm restart set up keeps them. A crash does not.
Recovery
Refill from the database. Combine the misses for the same key into one read.
Hazelcast
One member's JVM restarts.
Inside
The cluster promotes the backups on other members to owners and makes new backups.
The page service sees
Nothing, or a short pause while partitions move.
What survives
Every entry that had a backup on a surviving member.
What is lost
Entries whose owner and backup were both on the restarted member, which the default placement avoids.
Recovery
Automatic. The restarted member rejoins and takes partitions back.
Aerospike
One Aerospike node restarts.
Inside
In Community the index is rebuilt by scanning the records on SSD, a cold start. Enterprise fast restart keeps the index in shared memory across a clean restart. Other nodes serve the partitions this node mastered, from their replicas.
The page service sees
A short pause on the partitions that move. Reads keep working from the replica copies.
What survives
Every record on SSD and every replica on the other nodes.
What is lost
Nothing that was acknowledged with COMMIT_ALL, the default, because a replica already had it. Only writes still in this node's buffer that no replica had.
Recovery
Automatic. Partitions migrate back once the node is up.

Failure 2 of 5

The main server dies and a replica takes over

Redis
The primary dies. Sentinel or Cluster promotes a replica.
Inside
The replica received writes asynchronously, so it can be behind by the last few milliseconds.
The page service sees
Errors for a few seconds, then the new primary answers.
What survives
Everything the replica had received.
What is lost
The acknowledged writes the replica had not received. WAIT shrinks that window, it does not close it.
Recovery
Clients reconnect to the new primary. The old primary comes back as a replica.
Dragonfly
The primary dies. Redis Sentinel, the Kubernetes operator or your own tooling promotes the replica.
Inside
The same asynchronous replication as Redis: the replica can lack the last writes.
The page service sees
Errors until the promotion, then normal answers.
What survives
What the replica had received.
What is lost
The last acknowledged writes the replica did not have.
Recovery
Point the clients at the new primary.
Memcached
There's no replica. A dead server is a dead server.
Inside
Nothing happens inside. The client library keeps hashing keys to the dead server until it marks it down, so it doesn't know yet.
The page service sees
Timeouts for that server's keys, then misses once the client removes it from the ring.
What survives
Nothing from that server.
What is lost
Every item on it.
Recovery
Replace the server. Its keys refill from the database.
Hazelcast
A member dies. The cluster promotes the backups.
Inside
Each partition's backup on another member becomes the owner. The promotion is inside the cluster, no client change.
The page service sees
A short pause. Smart clients learn the new partition table.
What survives
Every entry with a synchronous backup, which is the default.
What is lost
A write whose owner died after applying it and before the backup acknowledged. The client's call is retried on the new owner, so it can run twice. With the indeterminate-state setting on, the client gets an error instead.
Recovery
Automatic rebalancing.
Aerospike
A node dies. Replicas on other nodes become masters.
Inside
The cluster agrees a new partition map.
The page service sees
A brief pause while the map updates. The client fetches the new map.
What survives
Every write that reached a replica, which with COMMIT_ALL is every acknowledged write.
What is lost
In AP mode with COMMIT_MASTER, writes the replica had not received. In strong-consistency mode, nothing that was acknowledged.
Recovery
Automatic. Migrations rebalance the copies.

Failure 3 of 5

The 'price changed' delete or message never arrives

Redis
The DEL after the price change fails, or the tracking message to a client is dropped.
Inside
The old copy stays in memory until its TTL ends. A client with tracking gets no message about a broken connection. The docs ask the client library to flush its copy itself.
The page service sees
The old price for up to the TTL.
What survives
The TTL bound.
What is lost
Freshness inside the TTL window.
Recovery
Retry the DEL. A client library whose tracking connection broke should flush its whole local copy.
Dragonfly
The same two failures as Redis.
Inside
Same again: the copy stays until the TTL. Only basic tracking exists.
The page service sees
Same as Redis: the old price until the TTL.
What survives
The TTL bound.
What is lost
Freshness inside the window.
Recovery
Retry the DEL. Drop local copies after a lost connection.
Memcached
The delete fails.
Inside
Nothing notices. Memcached never tells anyone that a key changed.
The page service sees
The old price until the TTL.
What survives
The TTL bound.
What is lost
Freshness inside the window, and any local copy you built stays stale on its own schedule.
Recovery
Retry the delete. A local copy needs its own short TTL.
Hazelcast
A Near Cache invalidation event is lost.
Inside
The owner sends invalidations after a change. They travel asynchronously and can be lost. The Near Cache also has its own TTL and max-idle time.
The page service sees
The old value from the Near Cache until its own TTL.
What survives
The owning member's copy is correct.
What is lost
Freshness in the client's local copy.
Recovery
Reconciliation, on by default, compares sent and received invalidation counts every 60 seconds and drops the affected copies. The local TTL ends the rest.
Aerospike
When Aerospike holds a cache copy, the delete of that copy fails.
Inside
The record stays until its TTL, if one was set. When Aerospike is the owner of the record there is no copy to invalidate.
The page service sees
The old record until the TTL, or the current one when Aerospike owns it.
What survives
The TTL bound, or full freshness as the owner.
What is lost
Freshness inside the window, in cache mode only.
Recovery
Retry the delete, or make Aerospike the owner of that record.

Failure 4 of 5

The cache is up but does not answer in time

Redis
A slow command, a big value or a network fault. GET times out.
Inside
The main thread is busy or the packet is lost. The value is still there.
The page service sees
A timeout, which isn't a miss.
What survives
Everything.
What is lost
Nothing, unless the code treats the timeout as a miss and floods the database. That's the mistake to avoid.
Recovery
Bound the timeout, allow one small retry, and cap database reads. Treat it as the cache being away, not as the key being gone.
Dragonfly
One shard thread is busy with a cross-shard transaction, or the network fails.
Inside
The other shards keep answering. The busy shard's keys wait.
The page service sees
Timeouts on some keys only.
What survives
Everything.
What is lost
Nothing.
Recovery
Same as Redis: bound the timeout, one retry, cap the database.
Memcached
One server does not answer.
Inside
The client library marks it down after a few failures and stops sending to it.
The page service sees
Timeouts, then misses for that server's keys.
What survives
The other servers.
What is lost
Nothing on the server itself.
Recovery
The client re-adds the server when it answers. Its keys may have expired meanwhile.
Hazelcast
A member pauses for garbage collection.
Inside
Operations on its partitions wait. The cluster may suspect the member and start moving partitions.
The page service sees
Slow calls on some keys, or a timeout.
What survives
Everything, on owners and backups.
What is lost
Nothing, unless the pause is long enough to be treated as a death.
Recovery
Tune the heap, or use off-heap memory in Enterprise. Set operation timeouts.
Aerospike
A node's SSD is slow, or the node is busy.
Inside
Reads on its partitions wait on the device. In AP mode the client can be sent to a replica.
The page service sees
Slow reads on some partitions, or a timeout.
What survives
Everything.
What is lost
Nothing.
Recovery
Client timeouts and a retry to a replica. Watch device latency.

Failure 5 of 5

The network splits the cluster in two

Redis
Redis Cluster splits. The smaller side has no majority of masters.
Inside
Masters on the smaller side stop answering queries after the cluster-node-timeout. The larger side elects replicas for the lost slots.
The page service sees
Errors on the smaller side, normal answers on the larger side.
What survives
Writes on the larger side.
What is lost
Writes accepted on the smaller side inside the timeout window.
Recovery
The split heals and the smaller side's masters become replicas, dropping their extra writes.
Dragonfly
One node, so a split only cuts some clients off from it.
Inside
Nothing happens inside.
The page service sees
Timeouts for the cut-off clients.
What survives
Everything.
What is lost
Nothing, unless your tooling promotes the replica while the primary still runs, which makes two primaries.
Recovery
Reconnect. Fence the old primary before promoting.
Memcached
Servers never talk to each other, so there is no cluster to split.
Inside
Each client sees some servers and not others.
The page service sees
Timeouts and misses for the unreachable servers.
What survives
Everything on every server.
What is lost
Nothing. But two clients may now fill different servers for the same key.
Recovery
Reconnect. The extra entries expire by TTL.
Hazelcast
The cluster splits into two smaller clusters.
Inside
Each side promotes backups and keeps serving. Both sides accept writes to the same map.
The page service sees
Normal answers on both sides, with different data.
What survives
Two versions.
What is lost
The smaller side's writes to keys the larger side also holds. The smaller cluster merges into the larger one, under the PutIfAbsent merge policy by default.
Recovery
Split-brain protection can refuse writes on the smaller side. Merge policies decide the rest.
Aerospike
The cluster splits.
Inside
In AP mode both sides keep serving their partitions and both may write. In strong-consistency mode a partition is served only by the side with a majority of the roster that holds a copy of it. A side with exactly half serves it only if it holds the master.
The page service sees
AP: answers from both sides. SC: errors on the smaller side.
What survives
AP: two versions. SC: one.
What is lost
AP: one version of each conflicting record at merge, by generation or last write. SC: nothing that was acknowledged.
Recovery
AP: migrations merge by the conflict policy. SC: the smaller side rejoins.

12 more dimensions

More things to compare

These are not drawn above. Correctness and scaling first, because they change the decision most. Each product gets one short answer and, where there is one, a warning.

Correctness

Expiry, eviction, invalidation

How does an old value leave the cache?

What it means: A copy of product 8812 can leave the cache three ways. It can time out: each copy carries a lifetime (a TTL) and is dropped when it runs out. It can be pushed out to make room when memory is full (eviction). Or the code that changed the price in the database can remove the copy on purpose (invalidation).
Why it matters: TTL measures entry lifetime. Invalidation can race with a delayed refill. For a strict age limit, track when the source read began and refuse data past its freshness deadline; eviction only frees space.

Redis
Each key can carry its own lifetime (a TTL).
But By default the policy is called noeviction, which means nothing gets dropped once memory hits the maxmemory limit. Commands that add new data return an error, while reads keep working.
Dragonfly
Each key can have a TTL, set with the same expiry commands as Redis.
But Eviction here is one on-or-off flag, not the several choices Redis gives you with maxmemory-policy. Without cache_mode turned on, a full server rejects new writes instead. Check the flags reference for your version.
Memcached
Items expire by TTL, and a full slab class evicts live items of that size.
Hazelcast
Each entry can have a TTL and a max-idle time (it's dropped if nobody reads it for that long).
But An entry that's locked stays put. It won't expire and it won't be dropped to free up memory while the lock holds. The message that clears a stale near-cache copy can also get lost.
Aerospike
Expiry is done by a background supervisor, which is off until you set it.
But A record with no expiry time, what Aerospike calls a void-time of 0, is never dropped to free up memory. The background process that removes expired records (nsup-period) must be turned on first.
Only then will the server accept a positive TTL, a lifetime setting. A namespace running in strong-consistency mode, meaning every copy stays in agreement, shouldn't depend on eviction.

Thundering herd

What stops a thousand misses at once from becoming a thousand database reads?

What it means: Product 8812 is popular. Its cached copy times out. In that same instant, a thousand page requests all miss and all go to the database for the same row. That rush is called a thundering herd, or a cache stampede. Something has to let one request refill the cache while the others wait or use the old value.
Why it matters: Without it, the cache protects the database only while nothing popular is expiring.

Redisnot supported
Nothing built in: your code takes a lock key or refreshes early.
Dragonflynot supported
Nothing built in either.
Memcached
The meta protocol has flags for this.
But This needs a client library that understands the newer meta protocol. Its commands work on one key at a time, not several.
Hazelcast
MapLoader is your code for fetching a missing entry.
But The loader runs once per missing key, but a thousand different missing keys are still a thousand database reads. Measure concurrent loads, timeouts and failure behavior on the deployed version.
Aerospike
When Aerospike is the source store, a missing record needs no backing-database refill.

Reading right after a write

After the price changes in the database, which copy can still answer with the old value?

What it means: The database gets the new price for product 8812. Then the cached copy has to catch up. In between, something can still answer with the old price: the copy on the shared server, a replica of that server, or a local copy inside the page service.
Why it matters: Decides whether the page can promise the new price on the next view, or only within a time bound.

Redis
The shared copy answers old until the DEL lands, and a replica until it receives that DEL.
Dragonfly
Same shape as Redis, with one difference: only basic tracking exists, so local copies are rarer.
Memcached
The server copy answers old until the delete lands, and nothing else can answer at all: there is no replica and no message from the server that a key changed.
Hazelcast
The owner answers new as soon as the write completes, and the backup is in step with it.
Aerospike
As the owner of the record, the master answers new at once.
But Strong-consistency mode needs an Enterprise licence that includes it, or Aerospike Cloud. In Community, AP mode, a replica read may be a moment old.

Cache unreachable, not empty

The cache is up, but a read times out. Is that a miss?

What it means: A miss means the key isn't there. A timeout means you don't know. If the page service treats a timeout as a miss, it reads the database, and a thousand timeouts become a thousand database reads at once.
Why it matters: Decides how the page service handles a timeout: a bounded wait, one small retry, and a cap on database reads. A timeout is unavailable, not absent.

Redis
One slow command blocks every client behind it, so a big value or a KEYS command can turn into thousands of timeouts at once.
Dragonfly
A slow operation blocks only the shard threads it touches.
Memcached
Each server answers on its own.
Hazelcast
A garbage-collection pause on a member stalls its partitions.
Aerospike
A slow SSD stalls reads on that node's partitions.

Scaling

Spreading data across servers

How are the keys split across servers, and who decides which server holds a key?

What it means: When the measured data and workload exceed one server’s budget, split keys across several servers. Someone has to decide which server holds product 8812. The client library can work it out from the key, or the servers can keep a map of key ranges to servers. Each such slice of the keys is called a partition, a shard, or a hash slot, depending on the product. The same rule decides how much data moves when a server is added or removed.
Why it matters: Decides whether two keys that must change together can land on the same server, and how much traffic a resize disturbs.

Redis
Redis Cluster splits the keys into 16384 hash slots, each owned by one primary node.
Dragonfly
Inside one node, the keys are split across the shard threads.
But The server supplies the data plane; cluster health management and automatic failover need a control plane. Current documentation defaults to emulated single-node cluster mode; explicitly configure and verify the deployed version.
Memcached
Servers know nothing about each other.
Hazelcast
271 partitions by default, spread across the members, with a backup of each partition on other members.
Aerospike
4096 partitions per namespace, assigned to nodes by a fixed rule (a deterministic map).

What limits capacity

Is the ceiling memory, SSD, connections or one core?

What it means: The hot set of products is about 8 GB today, and it grows. Stores that hold everything in memory are limited by the DRAM on each server. SSD-backed storage can hold data beyond DRAM capacity, but adds device I/O to some reads. Compare measured latency and total cost. A copy of the data kept on another server is called a replica. Splitting the data across several servers is called sharding, and each server's share is a shard.
Why it matters: Decides one big server versus many small ones, and how the cost grows as the data grows.

Redis
Memory per node, and one core per node for running commands.
Dragonfly
The memory and cores of one node.
But The numbers for how much work it can do per second, on the vendor's pages, come from the vendor's own tests. Measure it on your own workload before you rely on them.
Memcached
DRAM per server, plus flash through extstore for larger values.
Hazelcast
Plan for the entries on owners plus the configured backups, JVM overhead and operational headroom.
But Storing data outside Java's own memory area, what Hazelcast calls off-heap or NATIVE storage, is an Enterprise-only feature.
Aerospike
DRAM for the index (64 B per record per copy, times the replication factor) and SSD for the data.

Adding a server

When a server is added or removed, what moves, and does the page service notice?

What it means: Today five servers hold the copies. Adding a sixth means some keys must move to it. Products differ in who moves them, whether reads keep working during the move, and whether the client library has to learn the new layout.
Why it matters: Decides whether growing the cache is a click, a script, or a refill of the whole cache from the database.

Redis
Redis Cluster moves hash slots between primaries with a resharding command.
Dragonfly
One node grows by getting a bigger machine.
Memcached
Nothing moves between the servers.
Hazelcast
The cluster moves whole partitions to the new member on its own and makes new backups.
Aerospike
The cluster recomputes the partition map and migrates the partitions the new node now owns, in the background.

Data

Data model and updates

Bytes, collections or records with fields: what can change in one operation?

What it means: Product 8812 has a price, a view count and tags. Redis and Dragonfly offer typed values such as hashes and sets. Memcached stores byte values with numeric operations and conditional replacement. Hazelcast offers distributed collections and entry processors. Aerospike stores typed bins within a record. Compare how each updates this product without replacing all its data.
Why it matters: The data model determines the commands and the atomic update unit. A safe one-key change is different from a transaction across several keys.

Redis
Typed values per key: strings, hashes, lists, sets, sorted sets, streams and more.
Dragonfly
Product 8812 can be a hash with fields, the same as in Redis.
But Support is decided command by command. The published list marks the ones that are missing.
Memcached
Byte values, numeric operations and CAS.
Hazelcast
Map, queue, set, list, ring buffer, topic, and the CP subsystem's primitives (an atomic long, a fenced lock).
Aerospike
Records with typed bins: product 8812 can contain a price, view count and tags.

Value size and memory cost

How large can one value be, and what does each key cost in memory?

What it means: Product 8812's JSON is a few KB. Each product also costs extra memory for its key name, its expiry time and bookkeeping. That extra cost is called the per-key overhead, and every product has a size ceiling too. For stores that keep everything in memory, DRAM (the computer's own working memory) per key is what you pay for.
Why it matters: Sets the bill. The hot set in GB, plus the overhead per key, is the memory you have to buy.

Redis
A string value can be up to 512 MB by default (the proto-max-bulk-len limit).
But A value of several MB blocks the one thread that runs every command while it's being copied, so keep values small. Small hashes, lists and sets are stored in a compact form called listpack.
That happens as long as they stay below the *-max-listpack-* settings in redis.conf.
Dragonfly
The vendor README reports about 30% less memory than Redis for the same data when idle.
But The flags reference lists a maximum size for one value sent over the wire: 2147483648 bytes by default.
That's a limit built into the part of the code that reads incoming messages, not a size anyone has actually tested. Confirm it on your version.
Memcached
The default maximum item size is 1 MB, raised with the -I option.
Hazelcast
In Community Edition, entries live on the JVM heap, either in BINARY form (serialised, meaning turned into bytes) or as OBJECTs.
But Storing entries outside Java's own memory area, in what Hazelcast calls high-density memory (the NATIVE format), is an Enterprise-only feature.
Aerospike
The primary index costs 64 bytes of DRAM per record per copy.
But The Community Edition keeps the index in ordinary process memory, which is lost when the server restarts.
Enterprise options let you keep it in shared memory (shmem), in persistent memory (pmem), or entirely on SSD instead.

Operations

Who fills the cache

Does the cache fetch from the database itself, or does the application?

What it means: On a miss for product 8812, somebody must read the database and put the copy in the cache. In the common pattern the page service does it: check the cache, read the database, write the copy back. This is called cache-aside. Some stores can do it themselves: fetch on a miss (read-through) and pass writes on to the database later (write-behind).
Why it matters: With a loader the cluster calls your code on a miss instead of the page service. You still write it, and you still handle its failures. Write-through is not automatically a transaction spanning your database and every cache copy.

Redis
Cache-aside, done by your code: the page service asks Redis, misses, reads the database, and writes the copy back.
Dragonfly
Cache-aside: application code loads missing values.
Memcached
Cache-aside, with a proxy that can route and copy keys but never loads from a database.
Hazelcast
You give the cluster a MapLoader and MapStore (your code for reading and writing your database).
But Hazelcast can merge several changes to the same key into one, a feature called write-coalescing. If a key changes several times before the delayed write goes out, only the latest value reaches the database.
Aerospike
Aerospike can be the authoritative store or hold a cache-aside copy.
But The architecture example uses Aerospike as the product store itself. That is an explicit deployment choice, not a restriction on using it as a cache.

Clients and migration

Which client libraries and wire protocols work, and what does switching cost?

What it means: The page service talks to the cache through a client library that speaks the server's wire language (its protocol). If two servers speak the same protocol, the same client connects to both. That doesn't mean every command exists on both, or that both behave the same way when a server fails.
Why it matters: A shared protocol reduces migration work. Validate the commands, data types, client caching, timeouts and failover behavior your application actually uses.

Redis
The RESP protocol, Redis's own wire language (RESP2 by default, RESP3 after a HELLO command), with client libraries in every major language.
Dragonfly
A Redis client library connects to Dragonfly as it is, because Dragonfly speaks RESP, the Redis wire language.
But Using the same wire language doesn't mean it behaves the same way underneath. Test what happens when a server fails and a backup takes over (failover).
Also test what happens when memory runs low and old data gets dropped (eviction). Don't just check whether the commands run.
The Memcached page also doesn't say which versions of the Memcached protocol (text, meta, binary) it implements.
Memcached
Text, meta and binary protocols, with clients everywhere.
Hazelcast
Hazelcast has its own client libraries, including Java and Go.
Aerospike
Its own clients in the main languages, and its own wire protocol.

Licence and terms

Under what terms can you run it and ship it?

What it means: Several products here changed their licences after 2024. The terms decide whether you can run the cache inside a product you sell. They also decide whether a cloud provider may offer it as a managed service.
Why it matters: A hard limit for some organisations. Check at decision time, not from memory.

Redis
Redis 8.0 and later: your choice of RSALv2, SSPLv1 or AGPLv3.
But This detail can change, so check it again before you rely on it. Valkey is a separate project that split off from Redis and is now run by the Linux Foundation.
It has its own licence page.
Dragonfly
BSL 1.1.
But Read the 'additional use grant' section in the licence file itself for the current wording.
Memcached
BSD 3-Clause.
Hazelcast
Community Edition source is Apache 2.0 or the Hazelcast Community License, decided file by file.
But This can change. Confirm which features belong to which edition before you rely on it.
Aerospike
Community Edition server is AGPLv3, and its clients are Apache 2.0.
But This can change. Confirm which features need the Enterprise edition for your version. Some of them are sold as separate add-ons.

Guarantees, and where they stop

A guarantee is only as good as its boundary. Each line says for what unit it holds, and whether it is the default, an option, a paid edition, a managed service, the client library or a version. The mechanism is on the card or row it links to.

What a confirmed write survives how it works

Redisby default
Holds for: One primary. Replicas are asynchronous, disk is optional.
Dragonflyby default
Holds for: One primary, with snapshot files as the only copy on disk. Replicas are asynchronous.
Memcachedby default
Holds for: One server, memory only.
Hazelcastby default
Holds for: One entry and its synchronous backup, both in memory.
Aerospikeby default
Holds for: One record. A replica has acknowledged with COMMIT_ALL, the device flush comes later.

Changing several keys at once how it works

Redisby default
Holds for: Keys in one hash slot on one primary. No rollback after an error.
Dragonflyby default
Holds for: Keys on one node, across its shard threads.
Memcachedby default
Holds for: One key.
Hazelcastan option you turn on
Holds for: A transaction across members. A reader outside it can see half the change.
Aerospikepaid edition
Holds for: Several records inside one strong-consistency namespace. Several bins of one record everywhere.

Reading right after a write how it works

Redisby default
Holds for: One key on one primary. Replicas and tracked copies lag by the replication and message delay.
Dragonflyby default
Holds for: One key on its shard thread. The replica lags.
Memcachedby default
Holds for: One key on one server.
Hazelcastby default
Holds for: One entry on its owner. A Near Cache, if turned on, lags by up to 10 seconds.
Aerospikeby default
Holds for: One record on its master. AP replica reads lag. Reads that never lag need strong-consistency mode, Enterprise.

Expiry, eviction, invalidation how it works

Redisby default
Holds for: One key's TTL. Eviction is per server, by the maxmemory policy.
Dragonflyan option you turn on
Holds for: The TTL of one key, and no eviction at all until cache_mode is on.
Memcachedby default
Holds for: The TTL of one item, evicted inside its own slab class when that class is full.
Hazelcastby default
Holds for: One entry's TTL and max-idle. Eviction is per map, per member.
Aerospikean option you turn on
Holds for: One record's TTL. Expiry runs only when the supervisor is on.

2 scenarios

Two scenarios, before and after

Each scenario introduces its workload and starting conditions. Then a requirement changes. You see both sides.

Scenario 1

Serve product pages without overwhelming the database

How can we serve 50,000 product views per second without exceeding 5,000 database reads per second, even if a cache server fails?

Emma opens the kettle page. The page service checks a shared cache for product details and reads the product database only when the copy is missing or too old.

1. Initially

Record: one product as JSON, 2 to 6 KB
Catalogue: 20 million products. The ones people actually open (the hot set) are about 2 million, roughly 8 GB
Reads: 50,000 per second sustained, 3x that at peak
Writes: 200 per second (price and stock edits)
Latency target: a cache read under 2 ms for 99 out of 100 reads (the 99th percentile)
Product details may be up to 60 seconds old. Cache hits avoid database reads; misses spend the limited database budget.
Even if a cache server restarts, keep database reads at or below 5,000/sec and refuse data past its freshness deadline. Past 5,000 reads a second, answer with an error instead of an old copy.

Illustrative workload, not measured capacity.

2. What changes

Before, a product page could show the old price or stock for up to 60 seconds. Now, once an edit is saved in the database, the next product-page view must show the new price and stock.
The title, description and images can still be up to 60 seconds old. Traffic, the database read limit and failure requirements stay the same.

What still applies

At most 5,000 product-database reads per second, including recovery refills after a cache restart.
One region; no multi-key updates. Keep the stated traffic and cache-read latency targets.

A page never shows a product that was deleted more than 60 seconds ago.

Initial cache-aside rules

The page service asks the cache for product:8812. On a hit, about 98 reads in 100, it checks the copy's deadline. Inside the deadline it returns the copy. Past it, the hit counts as a miss.
On a miss it notes the time, reads the database, and stores the copy with a deadline 60 seconds after that noted time, not 60 seconds after the fill.
Example: the read starts at 0 s and returns $40. The fill lands at 8 s. The deadline is 60 s, not 68 s. Server clocks differ a little, so keep a margin of a few seconds inside the 60.

3. Why the new freshness rule breaks this recipe

A counterexample to delete-on-write: a read that started earlier can refill an old price after invalidation. The original deadline bounds its lifetime; it cannot make that old price current.

4. Which choices meet the complete requirements?

Ratings cover all requirements, including failures. The updated column adds the change to everything still required.

At an assumed 98% cache hit rate, database reads are 1,000/sec normally and 3,000/sec at peak. Every initial choice needs the deadline and refill rules above; measure the traffic and latency targets.

The updated ratings assess replacing the cache within this same design. Reading every price from the database would exceed its 5,000-read budget. A price editor that writes to the database directly, not through the map, never tells the map.

Then what? No cache product fixes this race between the database write and a slow fill. Change the design: the database owns price and stock, each record carries a version number, and an older cached copy is a miss. The database then takes a version read per page view, so give it read replicas or its own cache, and measure that first.

Product page: product tradeoffs before and after the change
Product	Initial requirements: details ≤60 seconds old	Updated requirements: current price / stock
Redis	good fit Why good fit: Stores product copies and can keep a replica ready for recovery. Apply the shared deadline and refill rules; reserve memory and test failover. Changes if: If persistence and the replica are dropped, a restart refills everything from the database.	poor fit Why poor fit: An earlier database read can refill the old price after the writer deletes the key. The next page view can therefore miss the committed price change.
Memcached	good fit Why good fit: Simple whole-product storage fits this read. A restart can empty the cache, so the shared refill limit is essential. Changes if: If two keys must ever change together, Memcached leaves the list.	poor fit Why poor fit: Delete on write does not prevent a delayed refill. This recipe cannot promise immediate freshness.
Dragonfly	can work Why it can work: Can serve independent product copies under the same application rules. Check the required commands, recovery behavior and measured capacity. Changes if: If a command the page uses is missing from the compatibility list.	poor fit Why poor fit: Same race as Redis: the worker threads do not change the order of a delete and a late fill, so the next view can still show the old price.
Hazelcast	can work Why it can work: A shared map and backups can serve this design. Any local Near Cache must obey the same deadline; embedded members require Java. Changes if: If the page service is not Java, the embedded option disappears and it becomes a shared server like the others.	poor fit Why poor fit: A database edit can leave an old price in the shared map or an optional Near Cache. MapStore does not coordinate every external writer and local copy, so the next page view is not guaranteed to see the edit.
Aerospike	can work Why it can work: Can store the copies under the same application rules. Compare operating cost for the 8 GB working set; field updates are not needed here. Changes if: If the 8 GB stays in memory, the SSD advantage is unused and the extra operations cost nothing back.	poor fit Why poor fit: As a cache, it can still hold an old price after the product database commits a change. Moving ownership of product writes into Aerospike would change this scenario’s data path; substituting the cache does not fix the stale read. Changes if: If Aerospike becomes the owner of the product record, there is no copy to go stale, and the whole data path changes.

Scroll the table sideways to compare both stages.

Scenario 2

Keep login checks fast and logout reliable

How can all gateways check login tokens quickly and keep them blocked after logout, even if a server fails?

Emma’s phone sends a login token with each request. Whichever API gateway receives it checks the same shared session store. This store holds the actual login records; there is no separate database to rebuild them from.

1. Initially

Record: session JSON, about 500 bytes
Active sessions: 30 million (15 GB of payload, before keys, metadata, replicas and headroom)
Reads: 200,000 per second, spread evenly across sessions
Writes: 2,000 per second (login and updates to existing sessions)
Latency target: under 1 ms at the 99th percentile
Each token has one independent session record in the shared store. Logout revokes that record.
Failure guarantees from the start: live sessions must survive a server restart, and a confirmed logout must never be undone. If current validity cannot be established, deny access.

Illustrative workload, not measured capacity.

2. What changes

The phone can now renew an expired login without asking Emma for her password. It presents a separate refresh credential to obtain a new session.
Logout must disable both records together. Otherwise the phone could use the remaining refresh credential to regain access.
A renewal that is already running must not create a new session after logout. So the check of the refresh credential and the creation of the new session run as one step with logout, not beside it.

What still applies

Sessions live 24 hours. Keep the traffic, restart guarantees, Go application and latency target.
Allow requests only after checking current validity and explicit expiry; deny missing, revoked, expired or unavailable state.
Confirm logout only after the change survives the stated failures.
Access may be unavailable during a network split. Recovery after losing every durable copy is outside this example.

Once a revocation (logging a session out) has been confirmed, that session is never accepted again.

3. How the design works

The session allows today’s request; the refresh credential can create tomorrow’s session. Logout must close both paths.

4. Which choices meet the complete requirements?

Ratings cover all requirements, including failures. The updated column adds the change to everything still required.

The failure guarantee determines the initial shortlist. Supporting a two-record operation does not remove an existing recovery problem.

Sessions: product tradeoffs before and after the change
Product	Initial requirements: independent sessions	Updated requirements: logout also blocks renewal
Redis	poor fit Why poor fit: The primary can confirm logout, fail before its replica receives the revocation, and be replaced by that replica with the token still valid. The append-only disk log (AOF) and WAIT, which requests replica acknowledgements, reduce loss exposure but do not guarantee that every failover preserves logout. Changes if: If a logout lost in the replication gap were acceptable, Redis with AOF and WAIT would fit.	poor fit Why still poor fit: Failover can still restore a revoked token. Redis can delete the two keys atomically when they share a Cluster hash slot (the same routing group), but that does not make the deletion survive every failover. Changes if: If both keys share a hash slot and a lost logout in the gap were acceptable, the atomic delete works.
Aerospike	can work Why it can work: Can work with Enterprise strong consistency: configure reads to see completed logout changes, and retain a revoked marker or deletion that survives recovery. Verify disk and recovery settings; do not let memory pressure discard live sessions. These settings and the latency target need validation. Changes if: If Enterprise is out of budget, strong consistency goes with it and this fit disappears.	can work Why it can work: Database 8 transactions in an Enterprise strong-consistency namespace can disable both records together. Renewal must check the credential and create the session in a transaction coordinated with logout. Keep current reads, logout changes that survive recovery, and denial when validity cannot be checked. Validate the stated traffic and latency with these settings. Changes if: If the two records were merged into one, the transaction is not needed, but strong consistency still is.
Dragonfly	poor fit Why poor fit: A replica or snapshot can lack the latest confirmed logout. Recovering that older session state can accept a revoked token, violating permanent revocation. Changes if: Same as Redis: if a lost logout in the gap were acceptable, it would fit.	poor fit Why still poor fit: Still the recovery gap. A transaction across the worker threads of one server does not close it. Changes if: Same as Redis: the atomic delete on one node works, the recovery gap stays.
Hazelcast	poor fit Why poor fit: During a network split, an IMap read on another side can still return the older valid session after logout was confirmed elsewhere. Backups alone do not prevent that stale authorization. Changes if: If split-brain protection refuses writes on the smaller side and reads go only to the larger side, it moves to can work.	poor fit Why still poor fit: Still the split-brain gap. On top of it, a reader outside the transaction can see the session gone and the refresh credential still valid, and a Near Cache copy can still say allowed. Changes if: If every gateway read inside the transaction and split writes were refused, it moves to can work.
Memcached	poor fit Why poor fit: A restart loses live sessions, violating the requirement that they survive without a backing database. Denying missing tokens prevents their use, but does not restore those sessions. Changes if: If sessions could be rebuilt from a database, the restart loss would not matter.	poor fit Why still poor fit: A restart still loses live sessions, and separate delete commands can stop halfway through the two records. Memcached has no multi-key transaction to disable both records as one operation. Changes if: If the two records were merged into one key, the half-done delete goes away. The restart loss stays.

Scroll the table sideways to compare both stages.

Decide

The summary of everything above, then the questions in the order that narrows the choice. Every cell links to the card or row that explains it.

Architecture
	Redis	Dragonfly	Memcached	Hazelcast	Aerospike
Where the copy lives	Shared server, optional tracked local copy	Shared server, basic tracking	Shared servers, no invalidation	Embedded in Java, or client-server	Separate cluster, index in memory
Who runs a request	One command thread	One thread per core, a shard each	Worker threads share one table	Partition threads per member	Many service threads per node
Spreading data across servers	16,384 slots across primaries	Shards per thread, cluster mode optional	Client hashes keys to servers	271 partitions with backups	4,096 partitions per namespace
What limits capacity	Memory and one core per node	Memory and cores of one node	DRAM per server, flash via extstore	JVM heap, two copies per entry	DRAM index, SSD data

Correctness
	Redis	Dragonfly	Memcached	Hazelcast	Aerospike
What a confirmed write survives	OK before replica or disk	OK before replica, snapshots	Nothing survives a crash	OK after one backup	OK after replica, device later
Changing several keys at once	Atomic in one hash slot, no rollback	Atomic on one node	One key at a time	Transactions, readers can see half	Bins atomic, records need Enterprise
Reading right after a write	Old until DEL, replicas and tracked copies lag	Old until DEL, replica lags	Old until delete, no other copy	Owner new at once, Near Cache lags	Master new, AP replica reads lag
Expiry, eviction, invalidation	TTL per key, eviction policies	TTL per key, eviction off by default	TTL per item, slab eviction	TTL and max-idle, eviction per map	TTL per record, supervisor off by default
Thundering herd	Your code, a lock key	Your code, a lock key	Meta protocol flags	MapLoader per missing key, no global cap	As owner, no refill needed

Scaling
	Redis	Dragonfly	Memcached	Hazelcast	Aerospike
One key gets hot	Replica or client-copy reads	One core's worth of reads	One server, a proxy can copy	Near Cache serves local hits	AP replica reads spread load
Adding a server	Slots move by command, clients follow redirects	A bigger machine, or cluster mode	Nothing moves, keys re-hash and refill	Partitions migrate automatically	Partitions migrate, clients fetch the map
Cache unreachable, not empty	One slow command times out everyone	Slow work blocks its shard only	Client marks a server down	GC pause stalls a member's partitions	Slow device stalls a node, replicas can answer

Operations
	Redis	Dragonfly	Memcached	Hazelcast	Aerospike
Who fills the cache	Cache-aside by your code	Cache-aside by your code	Cache-aside, a proxy routes	Read-through and write-through built in	Owner store, or cache-aside
Clients and migration	RESP, clients everywhere	RESP and Memcached protocol	Text, meta, binary protocols	Own clients, Java for embedded	Own clients and protocol
Licence and terms	RSALv2, SSPLv1 or AGPLv3	BSL 1.1	BSD 3-Clause	Apache 2.0 or Community License	AGPLv3 Community, Enterprise paid

Best fit
	Redis	Dragonfly	Memcached	Hazelcast	Aerospike
Reach for it when	Typed values, a client in every language	One big multi-core node, Redis commands	Plain byte copies, nothing else	Java services that want the data in-process	Records larger than memory, or the only copy

Which question first

Ask them in this order. Each yes narrows the shape, then the products on that shape.

Every no leads to the next question. No to 2: Set a TTL that matches how old is acceptable. Go on. No to 4: A memory store. Go on. No to 5: A shared server: Redis, Dragonfly or Memcached. No to 6: Memcached is the simplest, and it's enough.

Per-product fit, downside and what would change it are in Full details. The scenarios below show the same in context.

Running it
Product	Managed service	Operational load	Cost driver	Multi-region	Backup	Lock-in
Redis	ElastiCache, Memorystore, Redis Cloud	Low for one node, medium for Cluster	Memory per GB	Active-Active in Redis Software and Redis Cloud only	RDB snapshots	Low, RESP is widely spoken
Dragonfly	Dragonfly Cloud	Low, one node	Memory per GB, fewer nodes	Not in the open build	Snapshots, one per shard	Low, RESP
Memcached	ElastiCache. Memorystore for Memcached shuts down in 2029	Lowest	Memory per GB, flash via extstore	None built in	None, it refills	Low
Hazelcast	Hazelcast Cloud	Medium, a JVM cluster	Heap per GB, times two copies	WAN replication, Enterprise	Persistence, Enterprise	Medium, own clients
Aerospike	Aerospike Cloud	Medium to high	SSD per GB, index in DRAM	XDR, Enterprise	asbackup, now replaced by absctl	Medium, own clients

How to answer this in an interview

One worked answer for each scenario: requirements, decision, downside and the added requirement. Any conditional choice starts by naming the agreement it needs.

Product pages: bounded age, then current prices

What matters
Product details may be up to 60 seconds old, but database reads must stay below 5,000 per second, including cold-cache refills.
My decision, and why
I would evaluate Redis with a ready replica, a deadline anchored before the database read, and limited refills. Test the stated load and latency.
The downside
The replica costs memory. During recovery, the application must reject requests if it cannot serve an allowed copy within the database budget.
What would change my mind
If the next view must see every price edit, a delayed refill breaks this design. Reading every price from the database also exceeds its budget; changing the cache product alone is insufficient.

Sessions: reliable logout, then automatic renewal

What matters
Every gateway checks the same shared session store. A successful logout must stay effective after a server failure, and live sessions must survive restart. If the gateway cannot establish current validity, it denies access.
My decision, and why
I would evaluate Aerospike Enterprise in strong-consistency mode with current reads and logout records or deletions that survive recovery. Test these settings at the stated load and under-one-millisecond target.
The downside
This requires the Enterprise features and careful persistence, expiry and recovery settings. A gateway must not keep allowing requests from an old “token valid” answer after logout.
What would change my mind
Automatic renewal adds a second record to logout. I would evaluate Database 8 transactions for both records and coordinate renewal with logout; a renewal already running must not restore access.

What you will hear, and what to ask

“The database is the bottleneck.”
Ask: What is read most, and how old may that copy be?
Why this family exists
“The page must show the latest price.”
Ask: Who owns the price, and which copy can still answer old?
Row: Reading right after a write
“One celebrity product gets most of the traffic.”
Ask: Can replicas or local copies take the reads, and how old may they be?
Card: Hot key
“Sessions must survive a restart.”
Ask: Is the cache the only copy? Then what does OK mean?
Card: Durability
“Moving an item between carts must be all or nothing.”
Ask: Can two keys change atomically, and inside what boundary?
Card: Multi-key
“We are a Java shop.”
Ask: Would a copy inside the process remove the network trip, and how does it learn about changes?
Card: Placement
“What if the cache goes down?”
Ask: How many database reads can we afford while it refills?
When it fails

26 pages

Sources, and what we did not check

We checked every claim against the pages below in 2026-09. Limits, prices and licences change often, so check again before you quote them.

What we don't claim

The workloads in the scenarios are made up, and labelled that way. No throughput number here is a measurement.
Validate hit rate, miss latency, database fallback rate, evictions, replication lag and recovery time under failures. The product freshness-deadline design assumes fresh primary reads and bounded clock differences with a conservative safety margin; deny responses after the deadline, including slow in-flight reads.
The Dragonfly claims about memory use and command coverage come from the vendor's own documentation. No independent measurement we could compare was available at review time.
Licences were re-read in 2026-09, and several changed recently. Redis 8 offers three licences. Hazelcast Community is dual-licensed file by file. Dragonfly is BSL 1.1. And Aerospike strong consistency needs Enterprise. Re-check before citing.
Managed services (ElastiCache, Memorystore, Redis Cloud, Aerospike Cloud, Hazelcast Cloud) change how failover and persistence behave. The claims here are for deployments you run yourself.

The evidence mark on every claim, and the list of pages we checked, show in Full details.

Questions to ask first

The life of one copy

Five problems, drawn for each product

Where does the copy of product 8812 live?

50,000 reads a second arrive. Who does the work inside the server?

The server said 'saved'. Is Emma's session safe?

One key is read 80,000 times a second. Where does the load land?

Move the kettle from Emma's cart to Jake's. Can the cache change both keys together?

How each one is built

In our shop: read-through and write-through for product 8812

In our shop: product 8812 lives in Aerospike

When it fails

One of the two cache servers restarts with empty memory

The main server dies and a replica takes over

The 'price changed' delete or message never arrives

The cache is up but does not answer in time

The network splits the cluster in two

More things to compare

Correctness

Expiry, eviction, invalidation

Thundering herd

Reading right after a write

Cache unreachable, not empty

Scaling

Spreading data across servers

What limits capacity

Adding a server

Data

Data model and updates

Value size and memory cost

Operations

Who fills the cache

Clients and migration

Licence and terms

Guarantees, and where they stop

Two scenarios, before and after

Serve product pages without overwhelming the database

1. Initially

2. What changes

What still applies

Initial cache-aside rules

3. Why the new freshness rule breaks this recipe

4. Which choices meet the complete requirements?

Keep login checks fast and logout reliable

1. Initially

2. What changes

What still applies

3. How the design works

4. Which choices meet the complete requirements?

Decide

Which question first

How to answer this in an interview

Product pages: bounded age, then current prices

Sessions: reliable logout, then automatic renewal

What you will hear, and what to ask

Read more on this site

Sources, and what we did not check