Pick the structure so your question is one command
One flat keyspace: each key holds one typed value, optionally with a TTL. No tables, joins or secondary indexes.
Single-threaded, so it can’t scale?
Bad: More cores, more I/O threads
I/O threads only move bytes; commands still run one at a time.
Good: More shards
About one core per instance. Cluster spreads keys over more primaries.
Redis said OK. What can you still lose?
OK means “in the primary’s memory”. Persistence sets the crash window; asynchronous replication adds what the replica hadn’t received.
5
primaries, set by reads, not memory
8 million UPI sessions at ≈ 500 B is 4 GB, one 8 GB node. But 400k reads/s at ≈ 90k per primary needs five.
16,384 slots. Your key’s hash picks the node.
Each primary owns ranges of slots. In cart:{user42} only user42 is hashed, so a user’s keys share one slot.
Flash sale: every buyer hits stock:sku42. You add more shards.
The catch
No help: one key lives in one slot on one primary, capped by one core. Split it: stock:{sku42:0} … stock:{sku42:7}.
When to pick it, when not
- Pick: hot, short-lived or rebuildable data in RAM
- Not: the only copy of money or bookings
- Not: huge cold datasets or replayable logs
- Not: locks that guard correctness
Say it like this
Redis holds hot, rebuildable state: cache, rate limits, sorted-set leaderboards. Commands are atomic on one thread. AOF everysec risks ≈ 1 s, failover a bit more, so Postgres stays the source of truth.