Stackbook Logo
← Back to Tools

Redis Guide

Use Redis as a cache, session store and lightweight broker: data types, persistence, eviction, TTL patterns and the mistakes that cause outages.

4 min read

What it is and when to use it

Redis is an in-memory data structure server. It keeps data in RAM and exposes rich types such as strings, hashes, lists, sets, sorted sets and streams, with sub-millisecond latency. It is single-threaded for command execution, which makes each command atomic.

Use it for caching, session storage, rate limiting, leaderboards, distributed locks, job queues and pub/sub. Do not treat it as your primary system of record unless you accept its durability trade-offs, and remember your dataset must fit in memory.

Quick start

docker run -d --name redis -p 6379:6379 redis:7.2 \
  redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru

docker exec -it redis redis-cli

SET user:42:name "Ada" EX 3600
GET user:42:name
TTL user:42:name
HSET user:42 name Ada plan pro
HGETALL user:42
INCR page:views
ZADD leaderboard 1500 ada 1200 grace
ZREVRANGE leaderboard 0 9 WITHSCORES

Core concepts

Data types. Pick the type that matches the access pattern. Hashes store objects compactly, sorted sets give ranked lists, lists work as simple queues, and streams provide an append-only log with consumer groups.

Expiry. Set a TTL with EX or EXPIRE. Expired keys are removed lazily on access and by a background sampler.

Eviction. When maxmemory is reached, the policy decides what happens. allkeys-lru suits pure caches. volatile-lru only evicts keys with a TTL. noeviction returns errors on writes, which is right when Redis holds data you cannot drop.

Persistence. RDB snapshots are compact and fast to restore but lose writes since the last snapshot. AOF logs every write, and with appendfsync everysec you lose at most about a second. Many deployments enable both.

Replication and clustering. A primary replicates asynchronously to replicas. Sentinel provides automatic failover for a single shard. Redis Cluster shards data across 16384 hash slots for horizontal scale.

Common patterns

Cache-aside with a safe lock-style set:

SET lock:report:2026 token123 NX PX 30000

NX sets only if absent and PX gives a millisecond TTL, so the lock expires if the holder crashes. Release it with a Lua script that checks the token before deleting.

A fixed-window rate limiter in Lua-free form:

INCR rate:user:42:202606011205
EXPIRE rate:user:42:202606011205 60

A durable work queue with streams:

XADD jobs * type email to ada
XGROUP CREATE jobs workers 0
XREADGROUP GROUP workers w1 COUNT 10 BLOCK 5000 STREAMS jobs >
XACK jobs workers 1700000000000-0

Pitfalls

  • KEYS in production. It blocks the server while scanning everything. Use SCAN with a cursor.
  • Big keys. A multi-megabyte value or a list with millions of entries causes latency spikes on read, write and delete. Use UNLINK for asynchronous deletion and split large structures.
  • No TTLs on cache keys leads to unbounded memory growth.
  • Cache stampede. Many clients rebuild a hot key at once after expiry. Add jitter to TTLs and use a single-flight lock.
  • Exposed instance. Redis has no safe default exposure. Bind to private interfaces, require requirepass or ACLs, and use TLS across networks.
  • Assuming strong consistency. Asynchronous replication can lose acknowledged writes during failover, and WAIT only narrows the window.
  • Fork memory spikes. Snapshotting can double memory use under heavy writes. Leave headroom.

Check health with:

redis-cli INFO memory | grep used_memory_human
redis-cli --latency
redis-cli SLOWLOG GET 10
redis-cli MEMORY USAGE user:42

How it fits an architecture

Redis normally sits beside your database as a read-through cache or a shared session store, so stateless application servers can scale horizontally. It also fronts rate limiting at the API gateway, backs short-lived queues, and serves real-time features like presence and leaderboards. Treat the database as the source of truth, design every cached value so it can be rebuilt, and monitor hit ratio, evictions, memory and replication lag.

Key takeaways

  • Choose the data type that fits the access pattern, not just strings.
  • Always set TTLs and an explicit eviction policy.
  • Combine RDB and AOF only if you need durability, and know the loss window.
  • Avoid KEYS, big keys and blocking commands in hot paths.
  • Secure the instance with ACLs, private networking and TLS.
  • Use it as an accelerator for your database, not a replacement.