A giant hash map you can talk to over the network. One operation: GET key, one other: SET key value. Everything else — sorted sets, counters, queues — is built on top. The fastest databases in the world, because they barely look like databases.
The de facto standard. Strings, hashes, lists, sets, sorted sets, streams, pub/sub. Single-threaded per shard, brutally fast. Valkey is the open-source fork after the license change.
The old guard. Pure cache — no persistence, no data structures, just get/set with TTLs. Multi-threaded, dead simple.
AWS' managed key-value (and document). Predictable latency, autoscaling, global tables. The price model rewards good access-pattern design.
Edge key-value — eventually consistent, replicated to every PoP. Reads are fast from anywhere, writes propagate.
Strongly consistent KV for configuration and service discovery. Backed by Raft. Powers Kubernetes.
Distributed transactional KV — building blocks for higher-level databases (CockroachDB and TiDB sit on TiKV).
The classic. Compute or fetch the result, stash it under a deterministic key with a TTL, serve subsequent reads from RAM. Patterns: cache-aside (app reads cache, falls back to DB), read-through (cache fetches on miss), write-through (cache updates on every write). Mind invalidation — the second-hardest problem in CS.
Login session, JWT denylist, OAuth nonce, idempotency keys for payment requests. Short-lived, looked up by ID, written once. TTL handles cleanup automatically.
Atomic INCR on a key like rl:user:42:minute:2026-04-27T15:23, with a TTL. Token bucket, leaky bucket, sliding window — all a few Redis commands. Cassandra's counter columns play here too.
Redis sorted sets (ZADD, ZRANGE) give you "top N by score" in O(log N). Ranks, presence, trending lists, matchmaking queues — small data, hot reads, score updates.
Redis Streams and pub/sub for fan-out within a service. Not a Kafka replacement — no long retention, no exactly-once — but for "notify the websocket layer that user 42's data changed," it's perfect.
etcd / Consul / Cloudflare KV: small bits of config replicated everywhere, read on every request. Strong consistency matters here — flipping a flag should not race with a deploy.
user:42:sessions — and keep it in sync.allkeys-lru, volatile-ttl).One key getting a million reads per second. Pins a single shard's CPU while the rest of the cluster idles. Mitigate with client-side caching, request coalescing (single-flight), or sharding the key (counter:0..15).
A 50MB list. LRANGE on it blocks the single thread; replicas fall behind on the sync. Cap value sizes, paginate large structures, and run --bigkeys regularly.
A hot key expires; 10,000 requests miss simultaneously and all try to repopulate. The DB goes down. Fix with probabilistic early expiration, locking on miss (single-flight), or stale-while-revalidate.
Update DB, then update cache — and the second step fails. Invalidate (DEL) instead of writing through, accept TTLs as the worst-case staleness, or use change-data-capture from the DB to drive cache updates.
SCAN.