Redis
Redis is an in-memory data store that is far more than a cache. It supports strings, hashes, lists, sets, sorted sets, streams, bitmaps, and HyperLogLog. Sorted sets are perfect for leaderboards and priority queues. Streams provide a Kafka-like append-only log. Pub/Sub enables real-time messaging. Redis achieves sub-millisecond latency because all data lives in memory.
Redis is a whiteboard in the office kitchen: blazing fast to read and write, supports lists and sorted rankings, but if someone accidentally erases it (crash), you need the filing cabinet (PostgreSQL) to reconstruct everything. Never let the whiteboard be the only copy.
Persistence modes: RDB (point-in-time snapshots at intervals) and AOF (Append-Only File — logs every write). RDB is faster to load but you lose data since the last snapshot. AOF is more durable but slower and produces larger files. The recommended approach is RDB + AOF together, with AOF configured as 'everysec' (fsync every second — at most 1 second of data loss). Redis Cluster shards data across multiple nodes using hash slots (16384 total). Each key is assigned to a slot via CRC16(key) mod 16384. Redis Sentinel provides high availability for non-clustered setups: monitors the primary, detects failure, and promotes a replica. Lua scripting executes atomic operations on the server side — useful for complex operations like distributed locks (Redlock pattern) or rate limiting (sliding window with sorted sets).
Memory management: Redis uses jemalloc by default. The maxmemory-policy determines what happens when memory is full: volatile-lru (evict keys with TTL using LRU), allkeys-lru (evict any key using LRU), volatile-ttl (evict keys with shortest TTL), noeviction (return errors on write). For caching, allkeys-lru is usually correct. Active defragmentation (activedefrag yes) combats memory fragmentation that can cause Redis to use 2x the expected memory. Redis 7.0 introduced Redis Functions (replacing Lua scripts with better library management) and multi-part AOF for faster rewrite. Key operational concerns: single-threaded command execution (one slow command blocks everything — avoid KEYS * and large O(N) operations in production), and fork-based persistence (RDB/AOF rewrite forks the process, which on large datasets can cause latency spikes due to copy-on-write memory pressure).
Redis is my go-to for any workload that needs sub-millisecond latency: caching (obviously), but also session storage, rate limiting (sliding window with sorted sets), leaderboards (sorted sets with ZADD/ZRANGEBYSCORE), distributed locks (Redlock pattern), and real-time event processing (Redis Streams). I always deploy Redis with AOF persistence (everysec) plus RDB snapshots, and I never use Redis as the sole source of truth — it always sits in front of a durable primary database. Memory management is the key operational concern: I set maxmemory with an allkeys-lru eviction policy for caches, and monitor fragmentation ratio. The biggest gotcha is that Redis is single-threaded for command execution — one KEYS * command or a massive SMEMBERS on a set with millions of elements will block all other operations.
Using Redis as a primary database without a durable backing store. Redis persistence (RDB + AOF) reduces data loss risk but does not eliminate it — AOF everysec can lose up to one second of data, and catastrophic failures can corrupt both. Always design your system so Redis can be rebuilt from the primary database.