Redis Interview Prep

Redis (Remote Dictionary Server) is an in-memory data structure store used as a database, cache, message broker, and streaming engine. Data lives in RAM, making reads/writes microseconds fast.

Why is Redis So Fast?

• RAM storage — no disk I/O bottleneck
• Single-threaded event loop — no lock contention between threads
• Simple data structures — O(1) lookups for most operations
• Non-blocking I/O multiplexing — handles thousands of connections via epoll/kqueue

Common Use Cases

Redis Data Model

Every piece of data is stored as a key → value pair. The key is always a string. The value can be one of Redis's built-in data types: String, List, Hash, Set, Sorted Set, Stream, HyperLogLog, Bitmap, or Geospatial index.

Copy# Redis is a key-value store — every value has a key (name)
SET user:42:name "Alice"     # key = "user:42:name", value = "Alice"
GET user:42:name             # => "Alice"

# Check Redis version & info
INFO server
PING                         # => PONG (health check)

Single-Threaded Model

Redis uses one main thread to process commands. This sounds slow but isn't — because it avoids the overhead of thread synchronization and context switching. Since Redis is I/O-bound (not CPU-bound), one thread handles thousands of clients efficiently via multiplexed I/O.

Redis 6+ added I/O threads for reading/writing network data (not command execution), improving throughput on multi-core machines without breaking atomicity guarantees.

Universal Key Commands

CopySET    key value          # Store a value
GET    key               # Retrieve a value
DEL    key [key ...]     # Delete one or more keys (returns count deleted)
EXISTS key [key ...]     # Returns number of keys that exist (not 0/1)
TYPE   key               # Returns: string | list | hash | set | zset | stream
RENAME key newkey        # Rename a key (fails if key doesn't exist)
COPY   key destkey       # Copy value to a new key (Redis 6.2+)

KEYS   pattern           # Find keys matching pattern — NEVER use in production!
SCAN   cursor [MATCH pattern] [COUNT count]  # Safe iterative key scan

# Key metadata
OBJECT ENCODING key      # Internal encoding (ziplist, listpack, hashtable…)
OBJECT REFCOUNT key      # Reference count
OBJECT IDLETIME key      # Seconds since last access
DEBUG OBJECT key         # Detailed internal info

Why SCAN, Not KEYS

KEYS * blocks Redis until it scans every key in the database — catastrophic on large datasets. SCAN returns a cursor and a batch, letting Redis serve other commands between iterations.

Copy# Iterate all keys matching "user:*" in batches
SCAN 0 MATCH user:* COUNT 100
# Returns: [next_cursor, [key1, key2, ...]]
# Keep calling with next_cursor until cursor returns "0" (full cycle)

Key Naming Conventions

• Use colons as separators — they display as namespaces in Redis GUI tools
• Keep keys short but descriptive — keys are stored in memory too
• Include the object type and ID to prevent collisions
• Avoid spaces and special characters

Counting & Existence Patterns

CopyEXISTS user:42           # => 1 (exists) or 0 (doesn't)
EXISTS user:1 user:2 user:3  # => 2 (if 2 of the 3 exist)

# Count all keys in the database (instant, uses internal counter)
DBSIZE

# Select a database (Redis has 0-15 by default)
SELECT 0    # default database
SELECT 1    # switch to db 1 (isolated namespace)

# Move a key to another database
MOVE key 1

# Flush all keys (DANGEROUS — wipes entire database)
FLUSHDB     # wipes current DB
FLUSHALL    # wipes ALL databases

Core String Commands

Copy# Basic set and get
SET    username "alice"           # Store string
GET    username                   # => "alice"
MSET   k1 v1 k2 v2 k3 v3        # Set multiple at once (atomic)
MGET   k1 k2 k3                  # Get multiple at once → ["v1","v2","v3"]

# String inspection
STRLEN username                   # => 5 (length in bytes)
APPEND username "_admin"          # Appends → "alice_admin", returns new length
GETRANGE username 0 4             # Substring → "alice" (0-indexed, inclusive)
SETRANGE username 0 "bob"        # Overwrite at offset → "bob_admin"

Atomic Counters — the #1 Redis Pattern

CopySET    page:views 0
INCR   page:views            # => 1 (atomic: read + add 1 + write)
INCR   page:views            # => 2
INCRBY page:views 10         # => 12
DECR   page:views            # => 11
DECRBY page:views 5          # => 6
INCRBYFLOAT price 1.50       # => float increment (stored as string internally)

# Real-world: Rate limiting (10 requests per minute per user)
INCR   rate:login:user:42
EXPIRE rate:login:user:42 60  # Reset counter after 60s

SET Options (Combined Commands)

Copy# SET with expiry
SET  session:abc123 "user_data" EX 3600    # Expire in 3600 seconds
SET  session:abc123 "user_data" PX 3600000 # Expire in milliseconds
SET  session:abc123 "user_data" EXAT 1700000000 # Expire at Unix timestamp

# Conditional SET
SET  lock:resource "owner" NX             # Set ONLY if key does Not eXist
SET  config:debug "true" XX              # Set ONLY if key already eXists

# Combine NX + EX (atomic try-lock pattern)
SET  lock:checkout "worker1" NX EX 30   # Acquire lock, expires in 30s

# Deprecated equivalents (avoid in new code)
SETEX key 3600 value   # Same as SET key value EX 3600
SETNX key value        # Same as SET key value NX

# Get and set atomically
GETSET key newvalue    # Returns old value, sets new value
GETEX  key EX 60      # Get and reset TTL (Redis 6.2+)
GETDEL key             # Get and delete atomically (Redis 6.2+)

Strings as Binary Data

Copy# Store JSON (serialized object)
SET user:42 '{"name":"Alice","age":30}'
GET user:42   # => '{"name":"Alice","age":30}'

# Store image bytes, JWT tokens, serialized protobuf — Redis doesn't care
# Max value size: 512 MB

Use Strings When

• Storing single values: session tokens, feature flags, config values
• Atomic counters: page views, API rate limits, inventory counts
• Caching serialized objects (JSON/protobuf)
• Distributed locks (SET NX EX pattern)

Push & Pop Commands

Copy# Push to head (left)
LPUSH tasks "send-email"          # List: ["send-email"]
LPUSH tasks "resize-image"        # List: ["resize-image", "send-email"]

# Push to tail (right)
RPUSH tasks "generate-report"     # List: ["resize-image", "send-email", "generate-report"]
RPUSH tasks "a" "b" "c"           # Push multiple values at once

# Pop from head (left)
LPOP  tasks                       # => "resize-image" (removes & returns)
LPOP  tasks 2                     # Pop and return 2 elements (Redis 6.2+)

# Pop from tail (right)
RPOP  tasks                       # => "generate-report"

# Blocking pop — wait up to 30s for an item (perfect for job workers)
BLPOP tasks 30                    # Blocks until item available or timeout
BRPOP tasks 30

# Move atomically between lists
LMOVE source dest LEFT RIGHT      # Pop from source left, push to dest right

Reading the List

Copy>LRANGE tasks 0 -1        # All elements (0 = first, -1 = last)
LRANGE tasks 0 4         # First 5 elements
LLEN   tasks             # Length of list
LINDEX tasks 0           # Element at index 0 (no removal)
LINDEX tasks -1          # Last element

# Search and remove
LREM tasks 2 "send-email"    # Remove 2 occurrences of "send-email" from head
LREM tasks -1 "send-email"   # Remove 1 from the tail
LREM tasks 0 "send-email"    # Remove ALL occurrences

# Trim to keep only a range
LTRIM tasks 0 99         # Keep only first 100 items (discard the rest)

Queue vs Stack Patterns

Copy># Real-world: Activity feed — keep latest 100 items
LPUSH feed:user:42 "liked post 7"
LPUSH feed:user:42 "commented on post 3"
LTRIM  feed:user:42 0 99          # Cap at 100 entries
LRANGE feed:user:42 0 9           # Get latest 10 for display

Hash Commands

Copy# Set one or many fields
HSET user:42 name "Alice" email "alice@example.com" age 30
# HMSET is deprecated in Redis 4.0+, HSET now accepts multiple fields

# Get one or many fields
HGET  user:42 name                  # => "Alice"
HMGET user:42 name email age        # => ["Alice", "alice@example.com", "30"]
HGETALL user:42                     # => {name: Alice, email: ..., age: 30}

# Field existence & deletion
HEXISTS user:42 email               # => 1 (exists) or 0
HDEL    user:42 age                 # Delete field, returns count deleted

# Count & introspect
HLEN  user:42                       # => 3 (number of fields)
HKEYS user:42                       # => ["name", "email", "score"]
HVALS user:42                       # => ["Alice", "alice@example.com", "1500"]

# Atomic increment on a hash field
HINCRBY   user:42 score 100         # Add 100 to score → 1600
HINCRBYFLOAT user:42 balance 9.99  # Float increment

# Set only if field doesn't exist
HSETNX user:42 role "admin"        # Set "role" only if it doesn't already exist

# Scan fields in a large hash (like SCAN for keys)
HSCAN user:42 0 MATCH "a*" COUNT 10

Hash vs Separate String Keys

Copy# Real-world: Cache a user profile as a hash
HSET session:abc123 user_id 42 role "editor" expires_at 1700000000
HGET session:abc123 role   # => "editor"
EXPIRE session:abc123 3600 # Expire the whole session in 1 hour

Set Commands

Copy># Add members (duplicates ignored)
SADD tags:post:1 "redis" "database" "nosql"
SADD tags:post:1 "redis"          # Ignored — already exists → returns 0

# Read members
SMEMBERS  tags:post:1             # => {"redis", "database", "nosql"} (unordered!)
SCARD     tags:post:1             # => 3 (cardinality / count)

# Check membership
SISMEMBER tags:post:1 "redis"     # => 1 (is member)
SISMEMBER tags:post:1 "java"      # => 0 (not member)
SMISMEMBER tags:post:1 "redis" "java"  # Check multiple (Redis 6.2+)

# Remove members
SREM tags:post:1 "nosql"          # Remove "nosql"

# Pop a random member (remove & return)
SPOP tags:post:1                  # Remove and return random member
SRANDMEMBER tags:post:1 3         # Return 3 random members WITHOUT removing

Set Operations — the Superpower

Copy># Union — all unique members from both sets
SUNION  friends:alice friends:bob
SUNIONSTORE result friends:alice friends:bob  # Store result in new key

# Intersection — members in ALL sets
SINTER  friends:alice friends:bob
SINTERSTORE mutual_friends friends:alice friends:bob

# Difference — in first set but NOT in others
SDIFF   friends:alice friends:bob     # Alice's friends that Bob doesn't have
SDIFFSTORE alice_only friends:alice friends:bob

# Real-world: "Who to follow" suggestions
# Alice follows: {carol, dave}   Bob follows: {carol, eve}
SINTER followers:alice followers:bob   # => {carol} (mutual)
SDIFF  followers:bob followers:alice   # => {eve} (Bob follows, Alice doesn't → suggest to Alice)

Use Sets When

• Tracking unique items: unique daily visitors, unique IPs
• Tagging systems: posts tagged with multiple tags
• Social graphs: followers, following, blocked users
• ACL/permission systems: which users have access to a resource
• Set math (union, intersection, diff) for recommendations

Core Sorted Set Commands

Copy># Add members with scores
ZADD game:scores 9800 "alice"
ZADD game:scores 7200 "bob" 6500 "carol" 3100 "dave"

# Add with options
ZADD leaderboard NX 5000 "eve"    # Add only if NOT exists
ZADD leaderboard XX 5500 "eve"    # Update only if EXISTS
ZADD leaderboard GT 6000 "eve"    # Update only if new score > current (Redis 6.2+)
ZADD leaderboard LT 4000 "eve"    # Update only if new score < current

# Get score and rank
ZSCORE game:scores "alice"        # => "9800" (as string)
ZRANK  game:scores "alice"        # => 0 (0-indexed, lowest score = rank 0)
ZREVRANK game:scores "alice"      # => 0 (0-indexed, highest score = rank 0)

# Range queries — by rank
ZRANGE    game:scores 0 -1              # All, ascending by score
ZRANGE    game:scores 0 -1 WITHSCORES  # Include scores in result
ZREVRANGE game:scores 0 2              # Top 3, descending (deprecated in Redis 6.2)
ZRANGE    game:scores 0 2 REV          # Top 3 descending (Redis 6.2+ unified syntax)

# Range queries — by score
ZRANGEBYSCORE game:scores 5000 9999          # Members with score 5000-9999
ZRANGEBYSCORE game:scores -inf +inf          # All members
ZRANGEBYSCORE game:scores "(5000" 9999       # Exclusive lower bound (> 5000)
ZREVRANGEBYSCORE game:scores 9999 5000       # Descending by score

# Remove
ZREM game:scores "dave"                 # Remove member
ZREMRANGEBYRANK  game:scores 0 2        # Remove by rank range
ZREMRANGEBYSCORE game:scores -inf 1000  # Remove members with score ≤ 1000

# Count and pop
ZCARD  game:scores                     # Total member count
ZCOUNT game:scores 5000 +inf           # Count in score range
ZPOPMIN game:scores 3                  # Remove and return 3 lowest-score members
ZPOPMAX game:scores 3                  # Remove and return 3 highest-score members

# Increment a member's score (atomic)
ZINCRBY game:scores 200 "bob"          # bob's score: 7200 → 7400

Real-World Patterns

Copy># 1. Rate limiting with sliding window
# Score = Unix timestamp, member = request_id
ZADD rate:user:42 1700000000 "req-abc"
ZREMRANGEBYSCORE rate:user:42 -inf "(now-60)"  # Remove requests > 60s ago
ZCARD rate:user:42                             # Count in last 60s → compare to limit

# 2. Priority queue (task processing)
# Lower score = higher priority
ZADD tasks 1 "critical-alert"   # highest priority
ZADD tasks 5 "send-newsletter"  # lowest priority
ZPOPMIN tasks                   # Dequeue highest priority task

# 3. Time-based expiry of items in a set
# Score = expiry timestamp
ZADD expiring:sessions 1700003600 "session:abc"
ZREMRANGEBYSCORE expiring:sessions -inf (current_time)  # Clean expired

Setting Expiration

Copy># Set expiry on an existing key
EXPIRE  key 3600          # Expire in 3600 seconds (1 hour)
PEXPIRE key 3600000       # Expire in milliseconds
EXPIREAT  key 1700000000  # Expire at Unix timestamp (seconds)
PEXPIREAT key 1700000000000  # Expire at Unix timestamp (milliseconds)

# Check remaining time
TTL  key      # Seconds remaining (-1 = no expiry, -2 = key doesn't exist)
PTTL key      # Milliseconds remaining

# Remove expiry (make key persistent again)
PERSIST key   # Returns 1 if expiry was removed, 0 if key had no expiry

# Set with expiry in one command
SET key value EX 3600     # Most common pattern

# Get expiry as absolute timestamp (Redis 7.0+)
EXPIRETIME  key           # => Unix timestamp in seconds
PEXPIRETIME key           # => Unix timestamp in milliseconds

How Redis Expires Keys

Redis uses two complementary strategies — not just one:

1. Lazy expiration — when a key is accessed, Redis checks if it's expired. If yes, delete and return nil. Zero CPU overhead for untouched keys.
2. Active expiration — Redis runs a background job 10x/second randomly sampling 20 volatile keys and deleting expired ones. Repeats if >25% of sampled keys were expired.

Eviction Policies (maxmemory-policy)

When Redis hits its maxmemory limit, it must evict keys. Eight policies control this:

Copy># Configure in redis.conf or at runtime
CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

# For a pure cache: allkeys-lru (evict LRU from any key)
# For cache + persistent data mix: volatile-lru (only evict TTL keys)
# For frequency-biased workloads: allkeys-lfu (keeps "hot" keys)

LRU vs LFU

Pub/Sub Commands

Copy># Subscriber side — blocks and listens
SUBSCRIBE news sports weather       # Subscribe to specific channels
PSUBSCRIBE news.*                   # Pattern subscribe (glob: news.tech, news.sports, etc.)
UNSUBSCRIBE news                    # Unsubscribe from a channel
PUNSUBSCRIBE news.*                 # Unsubscribe from a pattern

# Publisher side — fire and forget
PUBLISH news "Server rebooting in 5 minutes"  # => 2 (number of clients that received it)
PUBLISH sports "Goal! 1-0!"

# Inspect subscriptions (server-side)
PUBSUB CHANNELS           # List all active channels
PUBSUB CHANNELS news.*    # Channels matching pattern
PUBSUB NUMSUB news sports # Subscriber count per channel
PUBSUB NUMPAT             # Number of pattern subscriptions

Pub/Sub Limitations

When to Use Pub/Sub

• Real-time notifications (chat messages, live dashboards)
• Cache invalidation signals across app servers
• Broadcasting config changes to microservices
• Live events where missing a message is acceptable

Copy># Real-world: Invalidate cache across all app servers
PUBLISH cache:invalidate "user:42:profile"
# Every server subscribed to "cache:invalidate" deletes that key from its local cache

Transactions — MULTI/EXEC

Copy># Queue commands, then execute all atomically
MULTI                         # Start transaction (queue mode)
  INCR inventory:item:5       # Queued (not executed yet)
  DECR available:item:5       # Queued
  LPUSH orders:pending 5      # Queued
EXEC                          # Execute all queued commands atomically

# Abort a transaction
MULTI
  SET foo "bar"
DISCARD                       # Discard all queued commands

Important: Redis transactions are not like SQL transactions. Individual command errors within EXEC do NOT roll back other commands — the rest still execute. Use transactions for atomicity (all-or-nothing delivery), not for SQL-style rollbacks.

WATCH — Optimistic Locking (CAS)

Copy># Pattern: read-modify-write with optimistic locking
WATCH balance:user:42         # Watch this key for changes

# (Read current value)
GET balance:user:42            # => "1000"

MULTI                          # Start transaction
  DECRBY balance:user:42 100  # Deduct 100
EXEC
# => nil if balance:user:42 changed since WATCH (transaction aborted)
# => [array of results] if no one changed it (transaction succeeded)

# Common retry loop (application-side)
# while True:
#   WATCH balance
#   val = GET balance
#   MULTI
#   SET balance (val - amount)
#   if EXEC != nil: break  # Success
#   # else: retry

Pipelines — Batching Without Atomicity

Copy># Without pipeline: 100 round-trips to server
for i in range(100):
    redis.set(f"key:{i}", i)

# With pipeline: 1 round-trip, 100 commands sent together
pipe = redis.pipeline(transaction=False)  # No MULTI/EXEC
for i in range(100):
    pipe.set(f"key:{i}", i)
pipe.execute()  # Send all 100 at once, get all responses back

RDB (Redis Database Snapshots)

Copy># redis.conf — trigger snapshot when N writes happen within M seconds
save 3600 1      # After 3600s if at least 1 key changed
save 300  100    # After 300s if at least 100 keys changed
save 60   10000  # After 60s if at least 10000 keys changed

# Manual snapshot commands
BGSAVE          # Fork child process to save in background (non-blocking)
SAVE            # Blocking save (avoids — blocks all clients)
LASTSAVE        # Unix timestamp of last successful save

# RDB file location
dbfilename dump.rdb
dir /var/lib/redis

AOF (Append Only File)

Copy># Enable AOF in redis.conf
appendonly yes
appendfilename "appendonly.aof"

# fsync policy — controls how often AOF is flushed to disk
appendfsync always    # Sync after EVERY command — safest, slowest
appendfsync everysec  # Sync every 1 second — good balance (default)
appendfsync no        # Let OS decide — fastest, most data risk

# AOF rewrite — compact the log periodically
BGREWRITEAOF           # Trigger manual compaction
auto-aof-rewrite-percentage 100   # Rewrite when AOF doubles in size
auto-aof-rewrite-min-size 64mb    # But only if AOF is at least 64MB

RDB vs AOF Comparison

Copy># Hybrid mode (Redis 4.0+) — recommended for production
aof-use-rdb-preamble yes  # AOF file starts with RDB snapshot, then AOF log

Replication Setup

Copy># On replica server — redis.conf
replicaof 192.168.1.10 6379   # Connect to master (replaces deprecated SLAVEOF)

# Or at runtime
REPLICAOF 192.168.1.10 6379
REPLICAOF NO ONE              # Promote this replica to master (manual failover)

# Inspect replication status
INFO replication
# Returns: role, connected_slaves, master_replid, master_repl_offset, etc.

# Replication is asynchronous by default
# For stronger durability (wait for replicas to acknowledge):
WAIT 2 1000   # Wait for 2 replicas to confirm, max 1000ms timeout

Key Replication Facts

• Replication is asynchronous — replicas may lag behind master by milliseconds
• Replicas are read-only by default
• On connection, replica gets a full RDB snapshot then streams commands
• Partial resynchronization (PSYNC) avoids full resync after brief disconnect

Redis Sentinel

Copy># sentinel.conf
sentinel monitor mymaster 192.168.1.10 6379 2  # Monitor master, quorum=2
sentinel down-after-milliseconds mymaster 5000  # 5s to declare master down
sentinel failover-timeout mymaster 10000        # 10s to complete failover
sentinel parallel-syncs mymaster 1             # 1 replica syncs at a time after failover

# Sentinel commands
SENTINEL masters                  # List monitored masters
SENTINEL replicas mymaster        # List replicas for mymaster
SENTINEL sentinels mymaster       # List sentinel peers
SENTINEL get-master-addr-by-name mymaster  # Current master IP:port

Quorum: Sentinels vote on whether master is down. Quorum = minimum votes needed to start failover (typically (n/2)+1 for n sentinels). Always run an odd number of Sentinels (3, 5).

How Key Distribution Works

Copy># Every key maps to a hash slot:
slot = CRC16(key) % 16384

# Hash tags — force keys to the same slot (use curly braces)
SET {user:42}.name "Alice"    # slot = CRC16("user:42") % 16384
SET {user:42}.email "a@x.com" # same slot as above!
# Without hash tags, different keys may land on different nodes
# Multi-key operations (MGET, MSET) require all keys on the same node

Cluster Setup Commands

Copy># redis.conf — enable cluster mode
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000

# Create cluster (redis-cli tool)
redis-cli --cluster create \
  192.168.1.10:7000 192.168.1.10:7001 192.168.1.10:7002 \
  192.168.1.11:7000 192.168.1.11:7001 192.168.1.11:7002 \
  --cluster-replicas 1   # 1 replica per master

# Cluster introspection
CLUSTER INFO             # Cluster state and stats
CLUSTER NODES            # All nodes and their slot ranges
CLUSTER SLOTS            # Slot-to-node mapping
CLUSTER KEYSLOT user:42  # Which slot does this key map to?
CLUSTER COUNTKEYSINSLOT 5432  # Keys in a slot

MOVED vs ASK Redirects

Cluster Limitations

• Multi-key operations only work if all keys are in the same slot (use hash tags)
• No cross-slot transactions (MULTI/EXEC fails with cross-slot keys)
• Lua scripts must access only keys in the same slot
• SELECT (database switching) not supported in cluster mode — only db 0

Pattern 1: Cache-Aside (Lazy Loading) — Most Common

Copy># App logic (pseudocode):
# 1. Try cache first
value = GET cache:user:42
if value is nil:
  # 2. Cache miss → query database
  value = db.query("SELECT * FROM users WHERE id = 42")
  # 3. Populate cache with TTL
  SET cache:user:42 value EX 3600

# Pros: Only caches what's actually needed
# Cons: Cache miss = slow first request (cold start)

Pattern 2: Write-Through

Copy># On every write, update BOTH cache and database synchronously
def update_user(id, data):
    db.update(f"UPDATE users SET ... WHERE id = {id}")
    SET cache:user:{id} serialize(data) EX 3600

# Pros: Cache always fresh, no stale reads
# Cons: Write latency increases (two writes), cache fills with rarely-read data

Pattern 3: Write-Behind (Write-Back)

Copy># Write to cache first, flush to DB asynchronously later
SET cache:user:42 data EX 3600     # Fast — just write to Redis
LPUSH write_queue "user:42:update" # Queue DB write for background worker
# Background worker flushes cache → DB periodically

# Pros: Fastest writes
# Cons: Data loss risk if Redis crashes before flush

Cache Stampede (Thundering Herd)

Copy># Solution 1: Mutex / single-filler lock
# Only one worker queries DB; others wait and get the cached result
lock_acquired = SET lock:cache:homepage 1 NX EX 5  # 5s lock
if lock_acquired:
    data = db.query(...)
    SET cache:homepage data EX 3600
    DEL lock:cache:homepage
else:
    # Wait briefly and retry from cache
    sleep(0.1)
    data = GET cache:homepage

# Solution 2: Probabilistic early reexpiry (PER)
# Refresh cache slightly before it expires based on recompute cost

# Solution 3: Stale-while-revalidate
# Return stale data immediately, refresh in background

Cache Invalidation Strategies

Correct Locking Pattern (SET NX EX)

Copy># Acquire lock — atomic, single command
token = random_unique_id()   # e.g., UUID
acquired = SET lock:resource token NX EX 30
# NX = only if Not eXists (acquire only if no one holds the lock)
# EX 30 = auto-release after 30 seconds (prevents deadlock if holder crashes)

if not acquired:
    # Lock is held by someone else — retry or fail fast

# Do critical work...
process_order()

# Release lock — ONLY if we still own it (verify token!)
# Use Lua script for atomic check-and-delete
lua_script = """
  if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
  else
    return 0
  end
"""
EVAL lua_script 1 lock:resource token

Why Check the Token Before Releasing?

Redlock Algorithm (Multi-Node)

For stronger guarantees across Redis Cluster or multiple independent Redis instances:

Copy># Redlock: acquire lock on N/2 + 1 independent Redis nodes
# 1. Record start time
# 2. Try to SET NX EX on all N nodes (e.g., 5 nodes)
# 3. If acquired on ≥ 3 nodes AND total elapsed < lock TTL → lock is valid
# 4. If failed → release on all nodes and retry with backoff

# Libraries implement this: redlock-py, redlock-rb, Redlock.net
# Single-node is fine for most cases; Redlock for multi-datacenter critical ops

Common Mistakes

Producing Messages — XADD

Copy># Add a message to the stream
XADD events:orders * action created order_id 101 user_id 42
# * = auto-generate ID (timestamp-sequence)
# Returns: "1700000001-0" (the message ID)

# Add with explicit ID (advanced — must be monotonically increasing)
XADD events:orders 1700000001-0 action created order_id 101

# Capped stream (keep only latest 1000 messages)
XADD events:orders MAXLEN 1000 * action shipped order_id 101
XADD events:orders MAXLEN ~ 1000 * action ...   # ~ = approximate cap (faster)

Reading Messages

Copy># Read by range (XRANGE)
XRANGE events:orders - +            # All messages (- = min, + = max)
XRANGE events:orders 1700000001-0 + # From specific ID to end
XRANGE events:orders - + COUNT 10   # First 10 messages

# Reverse range
XREVRANGE events:orders + - COUNT 5 # Latest 5 messages

# Read new messages from a position
XREAD COUNT 10 STREAMS events:orders 0   # 10 msgs from beginning
XREAD COUNT 10 STREAMS events:orders $   # Only NEW msgs arriving after this command

# Blocking read — wait for new messages (like BLPOP for lists)
XREAD BLOCK 0 COUNT 10 STREAMS events:orders $  # Block forever until new msg

# Stream info
XLEN events:orders                  # Total message count
XINFO STREAM events:orders          # Full stream metadata

Consumer Groups — Distributed Processing

Copy># Create a consumer group (start from beginning with 0, or $ for new msgs only)
XGROUP CREATE events:orders shipping-group 0
XGROUP CREATE events:orders billing-group  $

# Read as a consumer (each message delivered to only ONE consumer in the group)
XREADGROUP GROUP shipping-group worker-1 COUNT 5 STREAMS events:orders >
# ">" = undelivered messages only

# Acknowledge processing (removes from PEL - Pending Entry List)
XACK events:orders shipping-group 1700000001-0

# Check pending (unacknowledged) messages
XPENDING events:orders shipping-group - + 10

# Reclaim stuck messages (idle > 60s — worker crashed)
XAUTOCLAIM events:orders shipping-group worker-2 60000 0

Streams vs Pub/Sub vs Lists