Redis ("Remote Dictionary Server") is an in-memory data-structure server, most often used as a cache, session store, queue, or rate limiter. Because everything lives in RAM, reads and writes complete in well under a millisecond — and because RAM is finite and volatile, most of what matters operationally is how you handle memory limits, persistence, and failover.

A licensing note any 2026 evaluation should include: Redis left open source in March 2024, relicensing under RSALv2/SSPLv1, which prompted the Linux Foundation's Valkey fork — now the engine behind several managed offerings. Redis 8 (May 2025) added the OSI-approved AGPLv3, returning Redis itself to open source. In practice you will choose between Redis 8+, Valkey, or a managed service running either; the commands and concepts below apply to all of them.

Data Structures

Redis is key-value at its core, but values are typed structures: strings, hashes, lists, sets, sorted sets (leaderboards, priority queues), streams (append-only logs with consumer groups), plus bitmaps and HyperLogLogs. Every key can carry a TTL, which is what makes Redis a natural cache.

Eviction Policies: The Setting That Takes Down Production

When memory reaches maxmemory, the eviction policy decides what happens. The default is noeviction: writes start failing — and if maxmemory is unset, the process simply grows until the kernel OOM-kills it. For a pure cache you almost always want allkeys-lru (or allkeys-lfu); the volatile-* variants only evict keys that have TTLs. This is not a theoretical concern — we have documented a production outage caused by the default noeviction policy.

Persistence: RDB and AOF

Redis offers two persistence mechanisms. RDB takes point-in-time snapshots on a schedule: compact files and fast restarts, but a crash loses everything since the last snapshot. AOF (append-only file) logs every write, typically fsynced once per second, bounding loss to about a second at the cost of larger files and slower restarts. Production setups that care about the data commonly combine both. The design question is simple: a disposable cache can run with persistence off entirely; a session store, queue, or rate limiter cannot — if losing the dataset would page someone, configure and test persistence.

High Availability: Sentinel and Cluster

Replication in Redis is asynchronous, so a failover can lose writes the old primary acknowledged but never shipped — design for that. On top of replication there are two HA modes. Sentinel adds monitoring and automatic failover for a primary/replica set; the dataset must fit on one node. Redis Cluster shards data across nodes using 16,384 hash slots, scaling memory and write throughput, with the constraint that multi-key operations must hit keys in the same slot. Choose Sentinel when you need availability for a dataset one node can hold; choose Cluster when the data or write load genuinely exceeds one node.

Common Failure Modes

  • Cache stampede. A Redis restart or mass TTL expiry sends every request straight to the database at once. We saw this pattern in a cache failure that killed the database behind it. Mitigate with TTL jitter, request coalescing, and warm-up.
  • Hot keys and big keys. One heavily used key pins load to a single node, and commands like KEYS or fetching a huge set block the single-threaded event loop for everyone.
  • Treating the cache as the source of truth. If the only copy of the data lives in Redis without tested persistence and backups, it is not a cache — it is an unacknowledged database.

Quick Start

With Python's redis-py client:

import redis

r = redis.Redis(host="localhost", port=6379, db=0, decode_responses=True)
r.set("greeting", "hello", ex=60)  # 60-second TTL
print(r.get("greeting"))           # hello

Note decode_responses=True — without it, values come back as raw bytes (b'hello').

Redis rewards teams that treat it as real infrastructure: set maxmemory and an eviction policy deliberately, match persistence to what the data is worth, and monitor memory and replication lag. Sizing, HA design, and managed Redis/Valkey selection are bread-and-butter work for our cloud engineering practice.

Tags: #Redis #Database #Caching #Performance