Redis

Redis keeps data structures in memory and serves them over the network in well under a millisecond inside a region. Use it when the working set fits, the access is by key, and losing the cache is an inconvenience rather than an incident. Use Redis Cluster when one machine’s memory or CPU is not enough. Keys hash to slots, and a multi-key transaction only works for keys you have forced into the same slot with a hash tag.

Jobs it is good at

Cache. Cache-aside in front of Postgres. Set a TTL. Coalesce misses. Do not store the only copy of an order.

Counters and rate limits. INCR is atomic. A token bucket fits in a short Lua script so the refill and the take happen together. See the rate-limiting page.

Leaderboards. A sorted set gives you insert and top-K in log time of the set. One global set becomes a hot key. Shard by time bucket or by range and merge.

Locks and leases. SET key token NX PX ttl. The TTL is mandatory. Release with a compare-and-delete. A lock is not a queue, and it will not stay correct if the holder’s work outlives the TTL. Renew the lease with a heartbeat if the work is long, and make the work idempotent in case the lease expires anyway.

Streams. A small log with consumer groups, useful when you want Redis and the volume is modest. It is not a substitute for Kafka once you want long retention and many independent consumers.

Persistence and failure

RDB snapshots and AOF can persist Redis, and replication gives you a failover candidate. That still does not make it the ledger. Restores lose the last snapshot window. Failover can lose acknowledged writes depending on configuration. Say the loss mode if someone asks you to keep money there.

Eviction policy matters the day memory fills. allkeys-lru will throw away data. noeviction will start rejecting writes. Pick the one that matches whether this instance is a cache or a store.

Hot keys are the production incident. Replicate reads, or split the key. KEYS * and unbounded SMEMBERS are how you stall the single thread that serves everyone.