Redis

Redis stands for Remote Dictionary Server. At its core it is a single key-value store, but the values are not limited to strings. A value can be a hash (a small map of fields), a list, a set, a sorted set ordered by a score, a bitmap, a HyperLogLog, a stream, or a geospatial index. This is why Redis is often called a data structures server instead of just a cache.

Everything lives in memory. A lookup does not touch a disk, walk a B-tree, or cross a network of storage nodes, so a typical operation finishes in a few microseconds on the server and a fraction of a millisecond once you add network round-trip. A single Redis node can serve well over 100,000 operations per second on commodity hardware.

Redis is single-threaded for command execution. One command runs to completion before the next starts, so individual operations are atomic with no locks to manage. Modern versions use extra threads for network I/O, but the command processing model stays simple and predictable.

Because RAM is volatile, Redis offers two ways to survive a restart. RDB takes point-in-time snapshots of the whole dataset on a schedule, which is compact and fast to load but can lose the writes since the last snapshot. AOF (append-only file) logs every write command and replays it on startup, which loses less data but produces larger files. Many production setups run both.

Single-key atomicity covers simple cases, but Redis also gives you MULTI/EXEC transactions and Lua scripts that run server-side as one atomic block. Scripts are the common way to do read-then-write logic, like a rate limiter or a leaderboard update, without a race between two clients.

For scale and availability, Redis replicates from a primary to one or more read replicas asynchronously. Redis Sentinel watches the primary and promotes a replica if it dies. Redis Cluster goes further by sharding the keyspace across 16,384 hash slots spread over multiple primaries, so the dataset can outgrow a single machine's memory.

Keys can carry a TTL. Set a key to expire in 60 seconds and Redis removes it for you, which is how it behaves as a cache. When memory fills up, an eviction policy such as allkeys-lru or volatile-ttl decides what to drop.

Reach for Redis when you need very low latency and the access pattern is key-based: caching database query results or rendered pages, session storage, rate limiting, real-time leaderboards, counters, and pub/sub or stream-based message passing. It shines as a layer in front of a slower system of record like PostgreSQL or DynamoDB.

The main constraint is that your working set has to fit in RAM, and RAM is far more expensive per gigabyte than disk. A 100 GB dataset that costs little on disk can be costly to hold entirely in memory, so Redis is usually for hot data, not the full archive.

Durability is the other trade-off. Even with AOF set to fsync every second, a crash can lose up to a second of writes, and asynchronous replication means a failover can lose recently acknowledged writes. For data you cannot afford to lose, keep the authoritative copy in a durable database and treat Redis as an accelerator. Also avoid commands like KEYS in production, because scanning the whole keyspace on a single-threaded server blocks every other client.

Picture a news site that shows article view counts. Every page load would otherwise issue an UPDATE and a SELECT against the main database, which buckles under a traffic spike. Instead, each view runs INCR article:1234:views in Redis, an atomic in-memory increment that takes microseconds. A background job flushes the counts to PostgreSQL every minute.

The same site caches each rendered article: SET article:1234:html with a 5 minute TTL. The web server checks Redis first, and only on a miss does it render from the database and store the result. With a good hit rate the database sees a tiny fraction of the original load, and readers get pages served straight from memory.