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.

What Is Redis Used For?

The same engine covers a surprising number of jobs. The most common Redis use cases in production:

  • Caching — the classic use: keep hot database results or rendered fragments in RAM with a TTL, cutting read latency and database load.
  • Session storage — user sessions for web apps, shared across every application server.
  • Rate limiting — atomic counters with expiry make per-user or per-IP limits a few commands.
  • Queues and messaging — lists and streams back job queues and event pipelines (with consumer groups for fan-out).
  • Leaderboards and counters — sorted sets handle ranking, scoring, and top-N queries natively.
  • Real-time features — pub/sub for chat, notifications, and live dashboards.

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').

Frequently Asked Questions

Is Redis a database or a cache?

Both, depending on configuration. Redis is a full in-memory data store: with persistence (RDB/AOF) and replication enabled it can serve as a primary database for suitable workloads. In practice most teams run it as a cache or session store in front of a disk-based database — the key is deciding which role it plays and configuring persistence to match.

What type of database is Redis? Is it relational?

Redis is a NoSQL, in-memory key-value store — more precisely a data-structure server. It is not relational: there are no tables, no SQL, and no joins. You model data with keys pointing to typed structures (hashes, lists, sets, sorted sets, streams).

What does Redis stand for, and who created it?

Redis stands for REmote DIctionary Server. It was created in 2009 by Salvatore Sanfilippo ("antirez") and is written in C, which is part of why it is so fast.

How does Redis work?

Redis keeps the entire dataset in RAM and processes commands on a mostly single-threaded event loop, so operations complete in microseconds without lock contention. Durability comes from optional snapshots (RDB) and an append-only write log (AOF); availability from asynchronous replication with Sentinel or Cluster handling failover.

Redis vs Memcached — which should I use?

Memcached is a simpler, multi-threaded pure cache; it is fine when all you need is flat key-value caching. Redis adds typed data structures, persistence, replication, transactions, Lua scripting, and pub/sub — which is why it has become the default choice. If you might ever need more than GET/SET with TTL, start with Redis (or Valkey).

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.

Run this in production? Our AWS Managed Services team runs environments like this 24/7 — monitoring, incident response, patching and cost control by named senior engineers, from €3,000/month.

Tags: #Redis #Database #Caching #Performance