Databases
Redis
An in-memory key-value store with rich data types — strings, hashes, sorted sets, streams — delivering sub-millisecond reads, used for caching, sessions, rate limiters, leaderboards, queues and pub/sub. The speed comes from living in RAM. Plan for eviction policies and persistence (RDB or AOF), since memory is finite and volatile.
Purpose
Redis is an in-memory data store with rich types — strings, hashes, lists, sets, sorted sets, streams — serving reads and writes in well under a millisecond. It exists to hold the hot, fast-moving data that a disk-based database is too slow or too expensive to serve.
When to Use It
The classic quartet: cache in front of a database, session store, rate limiter (atomic counters with expiry) and pub/sub backplane for WebSocket fan-out. Sorted sets make leaderboards and priority queues trivial; streams give a lightweight event log.
Trade-offs
RAM is the speed and the constraint: datasets must fit in memory or be evicted, and memory is volatile — persistence (RDB snapshots, AOF log) narrows but does not eliminate loss windows. It complements a primary database; it rarely replaces one.
Implementation
Set TTLs on cache keys and choose an eviction policy (allkeys-lru for pure caches). Use atomic operations (INCR, SETNX, Lua) for counters and locks instead of read-modify-write races. Turn on AOF persistence if the data matters, and use replicas for read scaling and failover.