Redis, the
data-structure server.

Most people meet Redis as a cache: put a value under a key, read it back fast. That's true — it lives in memory, so reads and writes are microseconds, not milliseconds. But the deeper idea is that Redis is a data-structure server: a value isn't an opaque blob, it's a typed structure (a list, a set, a sorted set, a hash) with commands that operate on it atomically on the server.

That changes what you can do. Instead of reading a value, modifying it in your app, and writing it back (a race-prone round trip), you tell Redis "increment this counter," "add to this sorted set," "pop from this list" — and it happens atomically in one hop. The data structure lives where the data is. That's the difference between a cache and a Swiss-army server.

Five structures cover the vast majority of Redis usage. Knowing what each is for is most of knowing Redis.

The sorted set deserves a spotlight: it keeps members ordered by a numeric score with O(log N) add/update and rank queries — which is exactly a leaderboard, and also the backbone of sliding-window rate limiters and time-ordered indexes. Many "how would you build X in Redis?" answers are "a sorted set."

Surprisingly, core Redis executes commands on a single thread, via an event loop. That sounds like a limitation, but it's a feature: because one command runs to completion before the next, every operation is atomic with no locks, no race conditions, and no context-switching overhead. INCR, a sorted-set update, a multi-key transaction — all naturally atomic.

And it's still blazing fast because Redis is in-memory: the bottleneck is the network and memory bandwidth, not CPU concurrency. The practical lesson: keep individual commands cheap. A single expensive command (a huge KEYS * scan, a giant sorted-set range) blocks the whole server for its duration, so you avoid O(N) operations on big keys on the hot path.

Redis keeps data in RAM, which is why it's fast — and why durability needs care. If the process dies, in-memory data is gone unless it was persisted. Redis offers two mechanisms with different tradeoffs.

Many deployments run both: AOF for durability, RDB for fast restarts and backups. The key mindset: Redis can be durable, but its sweet spot is a fast layer where losing a little recent data on a crash is acceptable. If you need database-grade durability guarantees, that's a signal to reconsider (section 08).

RAM is finite, so Redis has to decide what to keep. Set a maxmemory limit and an eviction policy for when it's hit — most commonly allkeys-lru (evict least-recently-used) or allkeys-lfu (least-frequently-used), which turns Redis into a proper LRU/LFU cache that automatically drops cold data. Other policies evict only keys with a TTL, or refuse writes when full.

Independently, any key can be given a TTL (time to live) so it expires automatically — essential for cache freshness, session timeouts, and rate-limit windows. Between eviction (memory pressure) and TTL (explicit expiry), Redis keeps its footprint bounded without you manually cleaning up.

The data structures map cleanly onto classic patterns — this is why Redis is everywhere.

The pattern is always: pick the structure whose atomic operations are the feature. A leaderboard isn't "store scores and sort" — it's "a sorted set," and the rank query is one command.

A single Redis is a single point of failure and capped by one machine's RAM. Three mechanisms address that. Replication: a primary asynchronously copies its data to replicas, which serve reads and stand ready as failover targets. Sentinel: monitors the primary and automatically promotes a replica if it dies, giving high availability for a single logical dataset. Cluster: shards the keyspace across many primaries (by hashing keys into slots), so both capacity and throughput scale horizontally, each shard with its own replicas.

Redis is a fast layer, not a universal database. It's the wrong choice when your dataset is much larger than affordable RAM (memory is the cost ceiling), when you need rich relational queries or transactions spanning many entities (use a relational database), or when you need strong, guaranteed durability like a system of record (async replication and snapshotting can lose recent writes on failure).

Use it for what it's superb at: caching, counters, rate limiting, leaderboards, sessions, ephemeral queues, and real-time fan-out — a blazing-fast complement to your primary store, not a replacement for it. The right question isn't "can Redis do this?" (it usually can) but "is a fast, in-memory, structure-oriented layer the right shape for this data?"