Compare Caches and fast key-value stores

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

Keep often-read data in a fast store. It may be a copy of the kettle's product record that can be rebuilt, or the only record of Emma's login. The products differ in what they store, how old a copy can get, and what a crash loses.

How to decide. First decide what shape the data has and how it changes, such as one price field or a view counter. Then decide which reads may show an old copy, and what the page does when the cache doesn't answer.

Know these products already?Jump to the decision table The interview answer

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

The products

5 compared on this page. One line each, then what it is in plain words.

Redis
Lists, sets and hashes in memory, on a shared server
Your servers, or a managed service · A shared in-memory server
Redis keeps data in memory and gives it structures such as lists, sets and hashes. Each Redis server runs commands on one main thread, one after another, so two commands never interleave.
Copies on other servers and saving to disk are settings you turn on.
For example. The kettle page shows its price, its stock and a 'bought 12 times today' counter. Redis keeps them as one hash, so a sale changes one field with one command and every page service sees it.
Dragonfly
Redis commands, run on every core of one server
Your servers, or a managed service · A shared in-memory server
Dragonfly works with Redis clients, but runs requests on several cores at once. That can get more work out of one server. But it doesn't have every Redis command and feature, so switching takes more than a speed test.
For example. On sale day, the shop's one Redis server runs out of room on its single command thread while its other cores sit idle. Dragonfly takes the same client code and uses all the cores, so the shop gets more from that one server without splitting the keys across a cluster.
Memcached
A simple cache: a key goes in, bytes come out
Your servers, or a managed service · A shared in-memory server
Memcached stores and returns values by key, using several threads at once. The application decides how to encode each value. Unlike Redis, it has no lists or sorted sets, and servers don't copy data to each other.
If a server dies, its items are gone, and the application reads them again from the database.
For example. The shop only wants to stop reading the same product JSON from the database 50,000 times a second. Memcached keeps that JSON by key with nothing else to set up, and if a server is lost, the page reads the database again.
Hazelcast
A cluster that shares data and runs code where the data is
Inside your process, or a separate cluster · An in-memory data grid
Hazelcast spreads data across the members of a cluster and keeps a backup of each entry on another member.
It can run code on an entry where the entry is stored, so the application doesn't fetch it, change it and send it back.
But the cluster takes work to run, and changing one entry atomically doesn't mean several entries change together.
For example. The shop's page service is written in Java. Hazelcast runs inside it, so product 8812 is read from the service's own memory with no network trip, and a backup on another member keeps it when one instance restarts.
Aerospike
A record store with the index in memory and the data on SSD
Your servers, or a managed service · A record store with an index in memory and records on SSD
Aerospike organises data into namespaces, sets, records and bins, roughly like databases, tables, rows and columns. Sets don't need a fixed schema.
In the setup shown here, the index stays in memory while the records sit on SSD, so the data can be larger than RAM.
For example. The shop keeps 200 GB of carts and product records, more than it wants to pay for in memory. Aerospike keeps only the index in memory and the records on SSD, so a few servers hold all of it.

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.

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.

On this page

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 keeps a copy in the cache. The examples separate two prices: the old price a page may still show, and the price in the database that checkout uses.
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 Emma logs out, every API gateway must reject her old token. Later, the sessions scenario lets her phone renew a login on its own, using a second token called a refresh credential.

Across 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.

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.

Also worth knowing, not scored here

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.

Questions to ask first

Answer each one for your system. Read across: your answer on the left, where it points on the right.

How old may a cached value be, in seconds? Does the answer differ by field?
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.
Changes: Which copy can still show the old price after a change, and how that copy gets removed.
Why ask this. 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 happens to the database if every cached value disappears at the same moment?
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.
Changes: Durability of the copies, and the refill path on a miss.
Why ask this. 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.
Does any operation change several keys at once, where a half-done change would be wrong?
Yes
Redis or Dragonfly on one server, Hazelcast, or Aerospike Enterprise.
No
Memcached stays in the running.
Changes: Multi-key atomicity and where the keys must sit: one hash slot, one node, one namespace.
Why ask this. 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.
Does one key get most of the traffic?
Read-heavy countdown
local copies may fit.
Login checks
an old “token valid” copy must not allow access after logout.
A cluster's total capacity says nothing about one key, because all that key's reads land on one server.
Changes: Replicas that serve reads, and local copies inside the page service.
Why ask this. 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.

These can wait until the ones above are answered

How big is one value, and how many GB is the data you'll actually read?
Memory needed is the data, plus the extra bytes each key costs, times the number of copies. When that gets too expensive in RAM, a store that keeps records on SSD, such as Aerospike, becomes worth comparing.
Changes: Memory versus SSD, and one node versus a cluster.
Why ask this. 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.
Which language runtime does the application use?
Java
Hazelcast can live inside the process.
Anything else
a shared server, and Hazelcast only as a separate cluster.
Changes: Placement: a copy inside the process, or a shared server.
Why ask this. 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.

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.

Each step name links to where the products differ.

Read. The page service asks the cache for product:8812, one trip to a shared server or none to a local copy.
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.
Source read. On a miss the page service reads the database. A thousand misses for the same product must become one database read.
Fill. The page service writes the copy back with a lifetime. The server says OK. What that OK survives differs per product.
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.
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.

5 cards

Five problems, drawn for each product

Each card starts with one problem from the shop. Under it, one line per product says how it handles that problem. Pick a product to see its drawing and its full answer. 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.

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.

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.

Remember: A local hit skips the network trip. But it adds one more copy that can go stale, and the application must decide how old it may be.

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.

Redis

Redis runs commands one at a time on its main thread.

Network I/O and background work can use the other cores.
So a slow command makes every other command wait, and more cores don't change that.

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.

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.
So a confirmed logout can still be undone by a failover.

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.

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.

But Redis Cluster replica reads require READONLY on the replica connection. Check that the client routes those reads as intended.

Remember: Copies can spread the reads when an old answer is acceptable. Splitting one key into several spreads the writes, but then no single key holds the full value.

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.

Redis

It depends.MULTI/EXEC or a Lua script runs both changes with no other client's command in between.

In a cluster, both carts must be in one hash slot.
A shared hash tag does that: the same text in braces inside both key names.
If the second change fails, the first one stays done, so check inputs first.

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. Pick a product to open its drawing.

Redis

Redis Open Source 8.x · one primary and one async replica shown · optional RDB/AOF · cache-aside with 60 s TTL

Because one thread runs every command, a Lua script or a MULTI/EXEC batch runs with no other client's command in between. That does not undo earlier steps if one fails, and it does not save anything to disk.

Shape. One process keeps every key and value in memory. A main thread runs the commands one at a time. Optional I/O threads move the network traffic, and background tasks do work such as saving to disk.

GET product:8812 reaches the primary server. An I/O thread may read it off the network. The main thread then finds the key in memory and returns the value, or a miss.
SET changes the value and its expiry in memory, on the main thread. The OK comes back before any replica has the write, and before it is on disk. What reaches disk, and when, depends on the snapshot (RDB) and log (AOF) settings.
Commands run one at a time. Network reads and writes, and background work, can use other cores. So one slow command still makes every later command on that server wait.

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.

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. The list under each drawing says what breaks for each product. Pick one for the detail.

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.

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.

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.

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.

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.

12 more dimensions

More things to compare

These are not drawn above. Correctness and scaling first, because they change the decision most. Read across: the product on the left, its one-line answer on the right, and the catch under it.

Correctness

How does an old value leave the cache?
Expiry, eviction, invalidation. 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).
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 (a void-time of 0) is never evicted to free space. The server accepts a TTL above zero only after nsup-period, the background cleanup, is turned on.
A namespace in strong-consistency mode, where every copy stays in agreement, shouldn't depend on eviction.
Why it matters. A TTL counts from when the copy entered the cache, not from when the data was read. A slow refill can put an old price back right after a delete. For a strict age limit, note when the database read started, and refuse the copy once that time plus the limit has passed. Eviction only frees space.
What stops a thousand misses at once from becoming a thousand database reads?
Thundering herd. 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.
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 from the database.
But The loader runs once per missing key, but a thousand different missing keys are still a thousand database reads. So a cap on total database reads is still your job.
Aerospike
When Aerospike holds the only copy, a missing record is simply missing, with no database to refill from.
Why it matters. Without it, the cache protects the database only while nothing popular is expiring.
After the price changes in the database, which copy can still answer with the old value?
Reading right after a write. 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.
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.
Why it matters. Decides whether the page can promise the new price on the next view, or only within a time bound.
The cache is up, but a read times out. Is that a miss?
Cache unreachable, not empty. 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.
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.
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.

Scaling

How are the keys split across servers, and who decides which server holds a key?
Spreading data across servers. When the data or the traffic is too much for one server, the keys are split across several. 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.
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 stores and moves the data. Watching node health and promoting replicas needs a separate controller.
By default the current version presents itself as a cluster of one node, so real cluster mode has to be turned on.
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).
Why it matters. Decides whether two keys that must change together can land on the same server, and how much traffic a resize disturbs.
Is the ceiling memory, SSD, connections or one core?
What limits capacity. 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. A store that keeps records on SSD can hold more than memory, but some reads then wait for the SSD. 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.
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
With one backup, the cluster holds about two copies of every entry.
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.
Why it matters. Decides one big server versus many small ones, and how the cost grows as the data grows.
When a server is added or removed, what moves, and does the page service notice?
Adding a server. 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.
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.
Why it matters. Decides whether growing the cache is a click, a script, or a refill of the whole cache from the database.

Data

Bytes, collections or records with fields: what can change in one operation?
Data model and updates. Product 8812 has a price, a view count and tags. Redis and Dragonfly offer typed values such as hashes and sets. Memcached stores plain bytes, can add to a number, and can replace a value only if it hasn't changed. Hazelcast offers shared maps and lists, and can run your code on one entry where it is stored. Aerospike stores typed fields, called bins, inside a record. The question is how each one changes one field of this product without rewriting the whole record.
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
Values are plain bytes.
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.
Why it matters. The data model decides which commands exist, and how much one command can change safely. Changing one key safely is not the same as a transaction across several keys.
How large can one value be, and what does each key cost in memory?
Value size and memory cost. 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.
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.
Why it matters. Sets the bill. The hot set in GB, plus the overhead per key, is the memory you have to buy.

Operations

Does the cache fetch from the database itself, or does the application?
Who fills the cache. 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).
Redis
Cache-aside, done by your code: the page service asks Redis, misses, reads the database, and writes the copy back.
Dragonfly
Cache-aside: on a miss, the page service reads the database and writes the copy back.
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.
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. And write-through does not update your database and every cache copy as one all-or-nothing step.
Which client libraries and wire protocols work, and what does switching cost?
Clients and migration. 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.
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.
Why it matters. A shared protocol means less code to change. But a command your application uses may be missing, or a failover may behave differently.
Under what terms can you run it and ship it?
Licence and terms. 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.
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.
Why it matters. A hard limit for some organisations. Check at decision time, not from memory.

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

Redis
Holds for: One primary. Replicas are asynchronous, disk is optional.
by default
Dragonfly
Holds for: One primary, with snapshot files as the only copy on disk. Replicas are asynchronous.
by default
Memcached
Holds for: One server, memory only.
not supported
Hazelcast
Holds for: One entry and its synchronous backup, both in memory.
by default
Aerospike
Holds for: One record. A replica has acknowledged with COMMIT_ALL, the device flush comes later.
by default

Changing several keys at once how it works

Redis
Holds for: Keys in one hash slot on one primary. No rollback after an error.
by default
Dragonfly
Holds for: Keys on one node, across its shard threads.
by default
Memcached
Holds for: One key.
not supported
Hazelcast
Holds for: A transaction across members. A reader outside it can see half the change.
an option you turn on
Aerospike
Holds for: Several records inside one strong-consistency namespace. Several bins of one record everywhere.
paid edition

Reading right after a write how it works

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

Expiry, eviction, invalidation how it works

Redis
Holds for: One key's TTL. Eviction is per server, by the maxmemory policy.
by default
Dragonfly
Holds for: The TTL of one key, and no eviction at all until cache_mode is on.
an option you turn on
Memcached
Holds for: The TTL of one item, evicted inside its own slab class when that class is full.
by default
Hazelcast
Holds for: One entry's TTL and max-idle. Eviction is per map, per member.
by default
Aerospike
Holds for: One record's TTL. Expiry runs only when the supervisor is on.
an option you turn 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.

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.

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.

Why the new freshness rule breaks this recipe

Deleting the key on every price change is not enough. A database read that started before the change can put the old price back after the delete. The 60-second deadline limits how long it stays, but it is still the old price.

Which choices meet the complete requirements?

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

If 98 reads in 100 hit the cache, the database sees 1,000 reads a second normally and 3,000 at peak. Every product here needs the same deadline and refill rules from the normal flow.

The new ratings ask whether swapping the cache product fixes this design. Reading every price from the database would break its budget of 5,000 reads a second.

And a price editor that writes straight to the database never tells the cache.

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 the product copies, and a replica can keep them ready if the primary restarts. It still needs the deadline and refill rules, and memory for the replica. 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: Deleting the key when the price changes doesn't stop a slow read from refilling the old price. So the next view can still show it.
Dragonfly	can work Why it can work: Can hold the product copies under the same rules. Every command the page uses must be on its supported list. 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 rules. But it is more to run, and this page needs neither its SSD storage nor its field updates. 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.

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.

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.

How the design works

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

Which choices meet the complete requirements?

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

What a failure can lose decides this shortlist. A product that can lose a confirmed logout is out, and later support for two-record changes won't bring it back.

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. Reads must be set to see every finished logout. The revoked marker, or the delete, must survive a restart. And a full memory must never evict a live session. Whether it still meets 1 ms with these settings needs a test. 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. The earlier rules stay: reads that see every logout, logouts that survive a restart, and denial when validity can't be checked. Whether 200,000 reads a second at 1 ms still holds needs a test. 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.

The tables scroll sideways. The row label stays put.

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.

When the answer is no

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

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'd pick Redis with a replica kept ready. Each copy's deadline counts from when the database read started, and refills are capped.
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 show every price edit, a slow refill breaks this design. Reading every price from the database breaks its budget too. Swapping the cache product won't fix it.

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'd pick Aerospike Enterprise in strong-consistency mode. Reads always see the latest logout, and the logout record survives a restart. I'd test that at the stated load and the 1 ms 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 means logout must also disable a second record, the refresh credential. I'd use Database 8 transactions to disable both together. Renewal runs in a transaction with logout, so a renewal already running can't 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.
No hit rate, miss latency, eviction count, replication lag or recovery time here was measured. The 60-second deadline design assumes the database read returns current data, and that server clocks differ by only a few seconds. Keep a safety margin, and refuse any copy past its deadline, even one from a slow read still in progress.
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 products

Why this family exists

The shapes in this family

Questions to ask first

How old may a cached value be, in seconds? Does the answer differ by field?

What happens to the database if every cached value disappears at the same moment?

Does any operation change several keys at once, where a half-done change would be wrong?

Does one key get most of the traffic?

How big is one value, and how many GB is the data you'll actually read?

Which language runtime does the application use?

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

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

How does an old value leave the cache?

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

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

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

Scaling

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

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

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

Data

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

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

Operations

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

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

Under what terms can you run it and ship it?

Guarantees, and where they stop

Two scenarios, before and after

Serve product pages without overwhelming the database

Initially

What changes

What still applies

Initial cache-aside rules

Why the new freshness rule breaks this recipe

Which choices meet the complete requirements?

Keep login checks fast and logout reliable

Initially

What changes

What still applies

How the design works

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