Redis Interview Questions

Redis offers two persistence mechanisms:

RDB (Redis Database File)

• Creates point-in-time binary snapshots of the dataset
• Compact, fast to restore
• Can lose data between snapshots (configurable interval)
• File: dump.rdb

AOF (Append-Only File)

• Logs every write operation to an append-only file
• More durable (configurable fsync: every second, always, or never)
• Larger file size, slower to replay on restart
• File: appendonly.aof

Best Practice: Enable both RDB and AOF for data safety and fast restarts.

Redis 4.0+: AOF rewrite + RDB hybrid — uses RDB as base with incremental AOF on top.

# Configuration
save 900 1        # RDB: save if at least 1 key changed in 900 seconds
save 300 10       # RDB: save if at least 10 keys changed in 300 seconds
appendonly yes    # Enable AOF
appendfsync everysec  # AOF fsync: compromise between safety and speed

Redis Transactions use MULTI, EXEC, DISCARD, and WATCH:

1. MULTI — Marks the start of a transaction block
2. Commands — Queued, not executed immediately
3. EXEC — Executes all queued commands atomically (no other commands interleaved)
4. DISCARD — Flushes all queued commands

MULTI
SET account:1001:balance 100
INCRBY account:1002:balance 50
EXEC

Key characteristics:

• Redis transactions are all-or-nothing (if EXEC fails, nothing runs)
• But they are NOT rollback — if a command fails during execution, others still run
• Transactions are atomic — no other client can execute commands between MULTI and EXEC

WATCH implements optimistic locking for Redis transactions. You watch one or more keys before MULTI:

WATCH account:1001:balance
balance = GET account:1001:balance   # Client-side read (pseudo-code)
new_balance = balance - 50

MULTI
SET account:1001:balance new_balance
EXEC
# If another client modified account:1001:balance between WATCH and EXEC,
# EXEC returns nil (transaction aborted) — retry from WATCH

How it works:

1. WATCH key marks the key for monitoring
2. If any watched key is modified by another client before EXEC, the transaction is aborted
3. EXEC returns nil on abort, and the application should retry

This pattern is essential for read-modify-write operations without using a lock.

Pipelining allows sending multiple commands to Redis without waiting for individual replies. Commands are buffered and sent together, then all replies are read at once.

# Without pipeline — N round trips
SET key1 "a"    #  1 RTT
GET key1        #  1 RTT (total: 2 round trips)

# With pipeline — 1 round trip
pipeline do
  SET key1 "a"
  GET key1
end             # 1 RTT total

Performance gain:

• Without pipeline: RTT × N (e.g., 10ms × 1000 = 10 seconds for 1000 commands)
• With pipeline: RTT + server processing time (≈ 1 round trip total)
• Up to 100x improvement in throughput

Important caveats:

• Commands are not executed atomically (unlike MULTI/EXEC transactions)
• Clients must buffer replies in memory
• Too-large pipelines can consume excessive memory

You can combine both — use pipeline + MULTI/EXEC for atomic batch operations.

When Redis reaches maxmemory, it evicts keys based on the configured policy:

Recommendation:

• Caching use case: allkeys-lru (or allkeys-lfu if access frequency matters)
• Redis as primary DB: noeviction (prevent data loss)
• Mixed usage: volatile-lru (only evict cache keys with TTL)

LRU (Least Recently Used): Evicts keys that haven’t been accessed for the longest time.

# config
maxmemory-policy allkeys-lru

LFU (Least Frequently Used): Evicts keys that are accessed the least often over time.

# config
maxmemory-policy allkeys-lfu

Redis uses approximate LRU/LFU (not exact) — it samples a few keys and evicts the best candidate. This is much more memory-efficient than tracking full LRU/LFU info for every key.

1. Cache-Aside (Lazy Loading) The application checks Redis first. On miss, reads DB, stores in Redis, returns.

GET from Redis → miss → GET from DB → SET in Redis → return

2. Read-Through Cache sits between app and DB. The cache loads data from DB on miss.

3. Write-Through Data is written to cache AND DB simultaneously (synchronous).

4. Write-Behind (Write-Back) Data is written to cache first, then asynchronously persisted to DB.

5. Refresh-Ahead Cache proactively refreshes data before it expires (predictive).

Cache-Aside (Lazy Loading) is the most common caching pattern:

1. App requests data from cache (Redis)
2. If cache HIT → return data immediately
3. If cache MISS (key doesn't exist or expired):
   a. Query the database directly
   b. Store result in Redis with TTL
   c. Return data to client

async function getUser(id) {
  // Try cache first
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);

  // Cache miss — query database
  const user = await db.query('SELECT * FROM users WHERE id = ?', [id]);
  if (user) {
    // Store in cache with TTL
    await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
  }
  return user;
}

Pros:

• Only caches data that’s actually requested (cache stays lean)
• Simple to implement
• No stale data penalty beyond TTL

Cons:

• Cache miss penalty (3 network calls instead of 1)
• Initial request after deployment is always slow (cold cache)
• Stale data until TTL expires (if DB is updated directly)

Cache Stampede occurs when a popular cache key expires and many concurrent requests all try to regenerate it simultaneously, overwhelming the database.

Prevention strategies:

1. Mutex Lock — only one request regenerates

async function getData(key) {
  let data = await redis.get(key);
  if (data) return data;

  // Try to acquire lock
  const lock = await redis.setnx(`lock:${key}`, '1');
  if (lock) {
    await redis.expire(`lock:${key}`, 5);
    data = await expensiveQuery();
    await redis.setex(key, 3600, data);
    await redis.del(`lock:${key}`);
    return data;
  }

  // Wait and retry
  await sleep(10);
  return getData(key);
}

2. Early expiration — refresh before expiry Set TTL to e.g. 3600, but treat the key as stale after 3000 seconds. Refresh proactively.

3. Probabilistic early recomputation Randomly regenerate the cache before expiry based on probability (TTL - elapsed) / TTL.

Redis Replication allows a replica to be an exact copy of a primary (master) instance.

How it works:

1. Replica connects to primary and issues REPLICAOF master_host master_port
2. Primary starts a background save (RDB) or uses diskless replication
3. Primary sends the RDB file to the replica
4. Replica loads the RDB and applies buffered commands
5. After sync, replica receives all write commands as a continuous stream

# On replica
REPLICAOF 192.168.1.100 6379

# To break replication and make it a master
REPLICAOF NO ONE

Key characteristics:

• Asynchronous by default (primary doesn’t wait for replica ACK)
• One primary can have multiple replicas
• Replicas can have their own replicas (cascading)
• Replicas are read-only by default (configurable)
• Supports partial resynchronization (psync2) — after brief disconnections, replicas can pick up where they left off instead of full resync

Redis Sentinel provides high availability for Redis without manual intervention:

What Sentinel does:

1. Monitoring — Constantly checks if primary and replicas are working
2. Notification — Alerts system admins when something goes wrong
3. Automatic failover — If primary fails, promotes a replica to primary
4. Configuration provider — Clients ask Sentinel for the current primary address

How failover works:

1. Sentinel detects primary is down (quorum of sentinels agrees)
2. Sentinel elects a leader to perform failover
3. Leader promotes one replica to primary
4. Leader reconfigures remaining replicas to follow the new primary
5. Leader updates the configuration

Minimum setup: 3 Sentinel instances (for quorum) + 1 primary + 2 replicas

# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 2   # 2 = quorum
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Redis Cluster is a distributed implementation that shards data across multiple nodes automatically.

Key features:

• Automatic sharding — Keys are distributed across 16384 hash slots
• High availability — Each shard can have replicas (Node B can be replica of Node A)
• Decentralized — No central coordinator; nodes communicate via gossip protocol
• Partial failure tolerance — If a primary fails, its replica is promoted
• Minimal setup — At least 3 primary nodes recommended

Hash slot calculation:

HASH_SLOT = CRC16(key) mod 16384

Limitations:

• Multi-key operations only work if keys are in the same hash slot (use hash tags: {user:1001}.name)
• Only one database (no SELECT with multiple databases)
• No cross-slot transactions
• Client must support cluster protocol (MOVED redirections)

# Create a cluster
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  --cluster-replicas 1

Redis Cluster uses hash slot partitioning:

1. 16384 hash slots total
2. A key’s hash slot = CRC16(key) mod 16384
3. Each node owns a range of hash slots

Node A: slots 0-5460
Node B: slots 5461-10922
Node C: slots 10923-16383

Hash tags ensure multiple keys land in the same slot:

# Without hash tag — different slots
user:1001:name → slot 125
user:1001:email → slot 211

# With hash tag { } — same slot
{user:1001}:name → slot 152
{user:1001}:email → slot 152  (same!)

When a client connects to the wrong node, it receives a MOVED redirect telling it which node to query next.

Rule of thumb: Use Sentinel for datasets under 10-20GB, Cluster for larger datasets.

RDB (Redis Database File) performs point-in-time snapshots of the dataset.

# Configuration
save 900 1       # 1 change in 15 min → save
save 300 10      # 10 changes in 5 min → save
save 60 10000    # 10000 changes in 1 min → save

# Manual save
SAVE      # Synchronous (blocks)
BGSAVE    # Asynchronous (fork + child process)

Pros:

• Compact single file (dump.rdb) — easy to backup and transfer
• Fastest restart from persistence (loads RDB in memory)
• Minimal performance impact (uses fork()+COW, child does the work)
• Ideal for disaster recovery (send RDB to remote storage)

Cons:

• Can lose data between snapshots (up to N minutes of writes)
• BGSAVE uses fork() — can be slow with large datasets (>10GB)
• Not ideal if you need minimal data loss (use AOF instead)

AOF (Append-Only File) logs every write operation to a file. On restart, Redis replays the log to reconstruct data.

# Configuration
appendonly yes
appendfilename "appendonly.aof"

# fsync policies (how often to flush to disk):
appendfsync always      # Every write — most durable, slowest
appendfsync everysec    # Every second — good compromise (recommended)
appendfsync no          # OS decides — fastest, least durable

Pros:

• Most durable — with everysec, loses at most 1 second of data
• Append-only, no corruption issues (Redis can fix truncated files)
• Human-readable (can tail the file to see commands)
• Rewrite mechanism to compact file size

Cons:

• Larger file size than RDB
• Slower restart than RDB (must replay all commands)
• Can be slower than RDB under heavy write loads (with always fsync)

Over time, the AOF file grows as commands accumulate. AOF rewrite creates a compacted version:

How it works:

1. Redis forks a child process
2. Child reconstructs the current dataset in memory and writes a minimal AOF
3. Meanwhile, parent accumulates new commands in a buffer
4. When child finishes, parent appends the buffer to the new AOF
5. Parent atomically swaps the old AOF with the new one

What rewrite does:

• Instead of SET key 1, INCR key, INCR key → just SET key 3
• Removes expired keys
• Drops keys that have been deleted

# Manual trigger
BGREWRITEAOF

# Auto-trigger (config)
auto-aof-rewrite-percentage 100     # Rewrite if AOF grows by 100%
auto-aof-rewrite-min-size 64mb      # Minimum size to rewrite

In Redis 7+, AOF rewrite can happen in the background without fork using multi-threaded I/O.

Redis uses memory optimization techniques for small aggregate data types:

ziplist encoding: Small Lists, Hashes, and Sorted Sets are stored as ziplists (compact, contiguous memory) instead of linked lists or hash tables:

# Configurable thresholds
hash-max-ziplist-entries 512    # Hash → ziplist if ≤ 512 entries
hash-max-ziplist-value 64       # and each entry ≤ 64 bytes
list-max-ziplist-size -2        # List → quicklist (memory efficient)
zset-max-ziplist-entries 128    # Sorted Set → ziplist if ≤ 128 entries
zset-max-ziplist-value 64       # and each entry ≤ 64 bytes

Other optimizations:

• Intset — Small Sets of integers stored as sorted integer array
• Quicklist — Linked list of ziplists for Lists (memory + performance trade-off)
• Shared objects — Small integers (0-9999) are shared, not duplicated
• Memory alignment — Redis aligns data structures for efficient memory access

Use MEMORY DOCTOR to get memory optimization recommendations.

HyperLogLog is a probabilistic data structure for cardinality estimation (counting unique elements) using very little memory.

PFADD visitors "user:1001" "user:1002" "user:1001" "user:1003"
PFCOUNT visitors    # Returns ~3 (approximate unique count)

PFADD today "ip:1.2.3.4" "ip:5.6.7.8"
PFADD yesterday "ip:1.2.3.4" "ip:9.10.11.12"
PFMERGE all_visitors today yesterday   # Merge HLLs
PFCOUNT all_visitors                   # ~3 unique IPs across both days

Key characteristics:

• ~12KB memory per key regardless of cardinality
• 0.81% standard error (approximate, not exact)
• Can count up to 2⁶⁴ unique elements
• Merging two HLLs gives your union estimate with no extra error
• Cannot retrieve elements (only count approximation)

Use cases: Unique visitor counting, distinct IP addresses, search term cardinality.

Redis Pub/Sub implements a publish/subscribe messaging pattern:

# Subscribe to channels (client 1)
SUBSCRIBE news:tech news:sports

# Publish messages (client 2)
PUBLISH news:tech "New AI breakthrough!"
PUBLISH news:sports "World Cup finals today"

Key features:

• Fire-and-forget — Publisher sends, doesn’t wait for subscribers
• Fan-out — All subscribers of a channel get the message
• Pattern subscriptions — PSUBSCRIBE news:* to subscribe to all news channels

Limitations:

• No message persistence — If subscriber is offline, messages are lost
• No message acknowledgment — No guarantee of delivery
• No backpressure — Slow subscribers can cause buffer overflow
• Not suitable for reliable messaging — Use Redis Streams instead
• Scaling — Every subscriber gets every message (no consumer groups)

Redis Streams are an append-only log data structure introduced in Redis 5.0:

# Add entry to stream (auto-generated ID)
XADD mystream * sensor "temp" value 25.5

# Read from stream
XRANGE mystream - +                  # All entries
XREAD COUNT 10 STREAMS mystream 0    # First 10 entries

# Create consumer group
XGROUP CREATE mystream mygroup $
XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >

Key differences from Pub/Sub:

Use Streams when you need: Reliable messaging, event sourcing, activity feeds, job queues with acknowledgments.

Consumer Groups enable load-balanced message processing across multiple consumers:

Stream: order-events
Consumer Group: email-group
  ├── Consumer: worker-1 (processing order:1001, order:1002)
  ├── Consumer: worker-2 (processing order:1003)
  └── Consumer: worker-3 (idle)

# Create group
XGROUP CREATE order-events email-group $

# Worker reads (new messages assigned round-robin)
XREADGROUP GROUP email-group worker-1 COUNT 1 BLOCK 5000 STREAMS order-events >

# Acknowledge after processing
XACK order-events email-group 1700000000000-0

Features:

• Messages are distributed round-robin among consumers
• Each message is delivered to only one consumer
• Unacknowledged messages remain in the Pending Entries List (PEL)
• XPENDING shows pending messages; XCLAIM reassigns them if a consumer fails
• Consumers can reconnect and continue from where they left off

# Simple queue with List
RPUSH taskqueue "job1" "job2"
BRPOP taskqueue 0          # Blocks and returns "job1"

# Reliable queue with Streams
XADD taskqueue * type "email" to "user@example.com"
XGROUP CREATE taskqueue workers $
XREADGROUP GROUP workers worker1 COUNT 1 BLOCK 0 STREAMS taskqueue >
# Process and acknowledge
XACK taskqueue workers 1700000000000-0

Rule of thumb: Use Lists for simple FIFO where losing a message is acceptable. Use Streams for reliable message processing.

A basic distributed lock uses SET NX + EX:

// Acquire lock (atomically — both NX and EX in one command)
const lock = await redis.set(`lock:resource`, 'my-instance-id', {
  NX: true,        // Only set if key doesn't exist
  EX: 10           // Auto-release after 10 seconds (safety)
});

if (lock) {
  try {
    // Critical section
    await doWork();
  } finally {
    // Release lock (only if it's still our lock)
    const script = `
      if redis.call("GET", KEYS[1]) == ARGV[1] then
        return redis.call("DEL", KEYS[1])
      end
      return 0
    `;
    await redis.eval(script, 1, 'lock:resource', 'my-instance-id');
  }
}

Why Lua script for release? To ensure we only delete OUR lock — checking the value and deleting must be atomic.

Important considerations:

• Set a lock timeout (TTL) so locks don’t persist if the holder crashes
• Use a unique ID (UUID) so only the lock holder can release it
• Add a safety margin — work should complete before TTL expires
• For mission-critical locks, consider Redlock algorithm

Redlock is a distributed lock algorithm proposed by Redis creator Antirez for scenarios where locks must be safe across multiple Redis nodes.

How it works:

1. Get the current time (T1)
2. Acquire lock on N/2 + 1 independent Redis nodes sequentially (e.g., 3 of 5 nodes)
3. If acquired majority within lock validity time → lock is held
4. If not → release all locks and retry

// Simplified Redlock with 3 Redis instances
const instances = [redis1, redis2, redis3];
const lockKey = 'resource:lock';
const lockValue = uuid();
const ttl = 10000; // 10 seconds

async function acquireLock() {
  const startTime = Date.now();
  let acquired = 0;

  for (const instance of instances) {
    const result = await instance.set(lockKey, lockValue, 'NX', 'PX', ttl);
    if (result === 'OK') acquired++;
  }

  const elapsed = Date.now() - startTime;
  if (acquired >= 2 && elapsed < ttl) {
    return lockValue; // Lock acquired!
  }

  // Release all locks
  await releaseLock(lockValue);
  return null;
}

Controversy: Redlock has been debated by distributed systems experts (Martin Kleppmann). For most applications, single-node Redis with WATCH or a basic lock is sufficient.

Redis allows running Lua scripts on the server using EVAL:

# Simple Lua script
EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey "hello"

# Atomic compare-and-delete
EVAL "
  if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
  end
  return 0
" 1 mykey "expected-value"

Why Lua scripts are powerful:

• Atomicity — The entire script runs atomically (no other commands interleaved)
• Reduced network — Send logic to data instead of data to logic
• Complex operations — Implement multi-key logic atomically
• Reusable — Load with SCRIPT LOAD and run with EVALSHA

# Load script and run by hash
SCRIPT LOAD "return redis.call('GET', KEYS[1])"
# Returns: "4e6d..." (SHA1 hash)
EVALSHA "4e6d..." 1 mykey

Note: Lua scripts are replicated in replication/Cluster — they run on the primary and replicas (unless redis.replicate_commands() is used).

1. Use colons for namespacing

user:1001:profile
user:1001:sessions

2. Use consistent singular forms

// Avoid mixing
user:1001:name
users:1001:name ❌

3. Keep keys short but readable

u:1001:n         ❌ Too cryptic
user:1001:name   ✅ Good

4. Include the ID of the entity

article:42:comments

5. For Redis Cluster, use hash tags for related keys

{user:1001}:profile
{user:1001}:sessions  # Same hash slot!

6. Avoid overly long keys (>100 bytes wastes memory)

7. Use a consistent prefix per application (especially when sharing a Redis instance)

app1:user:1001
app2:user:1001

Key tools and commands:

1. INFO command — Overall server health

INFO stats    → total_commands_processed, instantaneous_ops_per_sec
INFO memory   → used_memory, fragmentation_ratio
INFO clients  → connected_clients, blocked_clients

2. SLOWLOG — Find slow queries

SLOWLOG GET 10          # Last 10 slow queries
SLOWLOG LEN             # Number of slow queries
SLOWLOG RESET           # Clear slow log
# Config: slowlog-log-slower-than 10000 (microseconds)

3. MONITOR — Real-time command stream (debugging only, not for production)

MONITOR    # Shows every command as it executes

4. LATENCY — Measure latency

LATENCY LATEST           # Latest latency events
LATENCY HISTORY command  # Latency history for a command
LATENCY DOCTOR           # Suggestions for latency issues

5. MEMORY DOCTOR — Memory optimization recommendations

MEMORY DOCTOR

6. Grafana + Prometheus — For production monitoring dashboards

Key metrics to watch:

• hit_ratio (keyspace_hits / (keyspace_hits + keyspace_misses))
• evicted_keys — sustained evictions indicate maxmemory is too low
• rejected_connections — too many clients
• fragmentation_ratio — > 1.5 may indicate memory issues

SLOWLOG records commands that exceed a configured execution time threshold:

# Configure threshold (microseconds)
CONFIG SET slowlog-log-slower-than 10000   # Log commands slower than 10ms

# View recent slow commands
SLOWLOG GET 5
# 1) 1) (integer) 14           # Unique ID
#    2) (integer) 1700000000   # Unix timestamp
#    3) (integer) 15000        # Execution time (microseconds)
#    4) 1) "KEYS"              # Command
#       2) "*"                 # Arguments
#    5) "127.0.0.1:6379"       # Client

# Number of slow queries
SLOWLOG LEN

# Clear slow log
SLOWLOG RESET

Common sources of slow queries:

• KEYS * (use SCAN instead)
• SMEMBERS on large Sets (use SSCAN)
• SORT with large datasets
• HGETALL on large Hashes
• ZRANGE on large Sorted Sets with very wide ranges

MONITOR streams every command processed by Redis in real-time:

redis> MONITOR
1700000000.000000 [0 127.0.0.1:6379] "SET" "mykey" "hello"
1700000000.000001 [0 127.0.0.1:6379] "GET" "mykey"

Why avoid in production:

• MONITOR can reduce Redis throughput by up to 50% or more
• Every command is output, creating high overhead
• The output buffer for the MONITOR client can grow and cause memory issues
• It’s a debugging tool, not a production monitoring tool

Alternatives:

• Use SLOWLOG to find problematic queries
• Use Redis’s built-in INFO stats for command counts
• Enable Redis’s command statistics with CONFIG SET commandstats yes

Memory fragmentation occurs when allocated memory can’t be fully utilized due to gaps between allocated blocks.

In Redis, fragmentation happens because:

1. Redis allocates and deallocates memory frequently
2. Different key sizes create non-contiguous usage patterns
3. The allocator (jemalloc by default) can’t perfectly fit every allocation

# Check fragmentation ratio
INFO memory
# used_memory_rss / used_memory = fragmentation ratio

# Example:
used_memory: 1.5GB         # Actual data size
used_memory_rss: 2.5GB     # RSS (what the OS has allocated)
# Fragmentation ratio: 1.67 (2.5/1.5) — elevated!

Interpreting fragmentation ratio:

• ≈ 1.0 — Ideal (RSS ≈ actual memory)
• > 1.5 — Significant fragmentation (consider restart or MEMORY PURGE)
• < 1.0 — Memory overcommit (some memory is shared/swapped)

Solutions:

1. Restart Redis (frees all memory)
2. MEMORY PURGE (ask allocator to reclaim memory
3. Use jemalloc (Redis default, good fragmentation characteristics)
4. Align key sizes where possible

• CONFIG GET pattern — Returns configuration parameters matching a glob pattern
• CONFIG SET parameter value — Changes configuration at runtime (without restart)

# Get configuration
CONFIG GET maxmemory          # * "100mb"
CONFIG GET *lru*             # All LRU-related configs
CONFIG GET *                  # ALL configuration (be careful — huge output!)

# Set configuration at runtime
CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru
CONFIG SET slowlog-log-slower-than 5000

Important:

• Runtime changes with CONFIG SET are temporary — lost on restart
• To make permanent, update redis.conf
• Use CONFIG REWRITE to save current runtime config to redis.conf

Both set key expiration, just with different time units:

• EXPIRE key seconds — Time-to-live in seconds (integer)
• PEXPIRE key milliseconds — Time-to-live in milliseconds (integer)

EXPIRE mykey 60       # Expires in 60 seconds
PEXPIRE mykey 60000   # Same: 60000 milliseconds = 60 seconds

Similarly:

• TTL key — Returns remaining time in seconds
• PTTL key — Returns remaining time in milliseconds
• SETEX key seconds value — Set with TTL in seconds
• PSETEX key milliseconds value — Set with TTL in milliseconds

PEXPIRE and PTTL are useful when you need finer granularity.

Redis uses two strategies for expiring keys:

1. Passive Expiration (Lazy)

• When a key is accessed (GET, EXISTS, etc.), Redis checks if it’s expired
• If expired, it’s deleted and nil is returned
• This means expired keys that are never accessed consume memory

2. Active Expiration (Periodic)

• Every 100ms, Redis runs a background cycle:
  1. Samples 20 random keys with TTL
  2. Deletes all expired keys found
  3. If >25% of sampled keys were expired, repeat from step 1
  4. Repeats for maximum 25% of the time slice (so it doesn’t block)
• This bounds the memory used by expired-but-unaccessed keys

Key point: The EXPIRE command doesn’t immediately delete the key — it marks it for eventual deletion. Redis guarantees that expired keys won’t be returned, but they may still exist in memory briefly.

The OBJECT command inspects Redis keys internally:

# Internal encoding (how the value is stored)
OBJECT ENCODING mykey
# "embstr" — small string
# "raw" — large string
# "ziplist" — small hash/list/zset
# "hashtable" — large hash/set
# "intset" — integer set

# Reference count (how many keys share this value)
OBJECT REFCOUNT mykey
# Numbers > 1 indicate shared objects (small integers)

# Idle time in seconds
OBJECT IDLETIME mykey
# How many seconds since the key was last accessed (used by LRU)

# Memory usage (approximate)
OBJECT FREQ mykey    # LFU frequency counter (logistic)

Use OBJECT ENCODING to verify internal optimizations are working (e.g., confirming small Hashes use ziplist).

The Redis latency watchdog records the stack trace of Redis’s main thread when it detects a command taking too long:

# Enable (time in milliseconds)
CONFIG SET watchdog-period 100   # Log stack trace if command takes > 100ms

# View logs (in server log, not Redis CLI)
# "Slow operation detected, watchdog fired."
# Shows the code path causing the latency

# Disable
CONFIG SET watchdog-period 0

Use case: Identifying exactly which code path is causing latency spikes. Unlike SLOWLOG (which shows the command + arguments), the watchdog shows the internal function call stack.

Note: The watchdog is a debugging tool and should be used carefully in production as it can affect performance.

Asynchronous Replication (Default):

• Primary executes write commands and immediately returns to client
• Replication to replicas happens in the background
• If primary crashes before replica receives the data, that data is lost
• Much better performance — primary doesn’t wait for replicas

# Default behavior
SET key value    # Returns immediately, replication is async

Synchronous Replication (WAIT command):

• WAIT blocks the client until a specified number of replicas acknowledge the write
• Provides stronger durability guarantee
• Higher latency — primary waits for replica ACK

MULTI
SET critical_key "important_value"
EXEC
WAIT 1 1000      # Wait for at least 1 replica to ACK, timeout 1000ms

Trade-off: Asynchronous = faster but potential data loss. WAIT = stronger durability but higher latency. Even with WAIT, Redis doesn’t guarantee full synchronous replication like some traditional databases (it’s “best effort”).

The CLIENT command manages client connections:

# List all connected clients
CLIENT LIST
# id=3 addr=127.0.0.1:6379 ... cmd=GET

# Kill a client connection
CLIENT KILL addr 127.0.0.1:56789

# Get/set the current connection name
CLIENT SETNAME my-app-worker
CLIENT GETNAME        # "my-app-worker"

# Pause all clients for a duration (testing failovers)
CLIENT PAUSE 10000    # Pause all clients for 10 seconds

# Set a max number of client connections
CONFIG SET maxclients 10000

# Kill idle connections
CLIENT KILL TYPE idle

Use CLIENT LIST to see blocked clients, idle connections, and the commands currently being executed.

Keyspace notifications allow clients to subscribe to events that affect keys (expiry, eviction, modification):

# Enable notifications (in redis.conf or CONFIG SET)
CONFIG SET notify-keyspace-events KEA
# K = keyspace events, E = keyevent events, A = all

# Subscribe to all expired key events
PSUBSCRIBE __keyevent@0__:expired

# Subscribe to key modifications in a specific namespace
PSUBSCRIBE __keyspace@0__:user:*

Event types:

• __keyspace@0__:mykey — Pattern: __keyspace@<db>__:<key>
• __keyevent@0__:del — Pattern: __keyevent@<db>__:<operation>

Notification types:

Use case: Cache invalidation, session cleanup, triggering background jobs when data expires.

Note: Notifications are fire-and-forget (no persistence. If no subscriber is listening, events are lost).

When to use each:

• MULTI/EXEC: Simple atomic batches where you just need to run several commands together
• Lua scripts: Complex operations with conditions, loops, or where one command’s result determines the next command

Redis Cluster handles failover automatically:

Failure detection:

1. Each node sends PING/PONG to other nodes (gossip protocol)
2. A node is marked PFAIL (possibly failed) if another node can’t reach it
3. If majority of primaries agree it’s PFAIL, it becomes FAIL

Failover process:

1. A replica of the failed primary initiates the failover
2. The replica votes among all primaries to become the new primary
3. If it gets majority votes, it becomes the new primary
4. The new primary starts accepting writes
5. When the old primary comes back, it becomes a replica of the new primary

Automatic failover conditions:

• The replica’s primary is marked as FAIL
• The replica’s data is reasonably up-to-date (within a configurable threshold)
• The replica has a higher “rank” (more complete replication)

Manual failover (maintenance):

CLUSTER FAILOVER       # Graceful — replica becomes primary
CLUSTER FAILOVER FORCE # Force without grace period
CLUSTER FAILOVER TAKEOVER # Emergency, no consent needed

The Cluster bus is a separate communication channel between Redis Cluster nodes:

• Port: Base port + 10000 (e.g., 6379 → 16379)
• Protocol: TCP-based binary protocol (not Redis protocol)
• Purpose: Internal cluster management

What travels on the cluster bus:

1. Gossip messages — Nodes share information about other nodes (PING/PONG)
2. Configuration propagation — Hash slot ownership changes
3. Failure detection — PFAIL/FAIL status propagation
4. Voting — During failover elections
5. Replica synchronization — Partial sync coordination

The cluster bus is critical for cluster operation — if the bus port is blocked by a firewall, nodes can’t communicate and the cluster will fail.

Sentinel failover process:

1. Subjective Down (SDOWN):

• A single Sentinel marks the primary as SDOWN if it’s unreachable for down-after-milliseconds

2. Objective Down (ODOWN):

• Other Sentinels are queried
• If quorum number of Sentinels agree the primary is down → ODOWN

3. Leader Election:

• Sentinels vote to elect a leader to perform the failover
• The first Sentinel to reach quorum votes becomes leader

4. Failover Execution:

• Leader selects the best replica to promote (based on priority, replication offset, run ID)
• Leader sends SLAVEOF NO ONE to the chosen replica
• Leader reconfigures other replicas to follow the new primary
• Leader updates the epoch (version number for configuration)

5. Client reconnection:

• Clients should use Sentinel to discover the new primary
• SENTINEL get-master-addr-by-name mymaster

Conclusion:

• Use Pipeline when you need performance (independent commands, no atomicity needed)
• Use MULTI/EXEC when you need atomicity (critical operations, read-modify-write)
• Use Pipeline + MULTI/EXEC for the best of both worlds (atomic batch with a single round trip)

RPOPLPUSH source destination atomically removes the last element from source and pushes it to the start (left) of destination:

RPUSH queue "task1" "task2" "task3"
RPOPLPUSH queue processing_queue
# Returns "task3" (popped from queue)
# queue: ["task1", "task2"]
# processing_queue: ["task3"]

Use case — Reliable Queue:

1. Worker pops from the main queue and pushes to a processing queue (RPOPLPUSH)
2. After successful processing, the worker removes from the processing queue (LREM)
3. If the worker crashes, the task remains in the processing queue (can be retried)

BRPOPLPUSH is the blocking version — waits for an element if the queue is empty.

In Redis 7+, BRPOPLPUSH is deprecated in favor of BLMOVE:

BLMOVE queue processing_queue RIGHT LEFT 0

The SORT command sorts the elements of a List, Set, or Sorted Set:

RPUSH scores 50 30 80 10 60
SORT scores    # Returns [10, 30, 50, 60, 80]

# Descending
SORT scores DESC    # [80, 60, 50, 30, 10]

# Limit results
SORT scores LIMIT 0 3    # [10, 30, 50] (first 3)

# Sort by external keys (sorting by a related hash field)
SORT user:ids BY user:*->age GET user:*->name

Advanced SORT (BY/GET):

# Given user IDs: [1, 2, 3]
# And hashes: user:1 (name: "Alice", age: 30), user:2 (...)
SORT user:ids BY user:*->age GET user:*->name
# Returns user names sorted by age

Warning: SORT can be slow on large datasets. Consider using Sorted Sets instead. SORT is being deprecated in Redis 7+ in favor of SORT_RO (read-only) and explicit data structure commands.

Redis has built-in geospatial commands using Sorted Sets:

# Add locations
GEOADD cafes 13.361389 38.115556 "Palermo"    # longitude latitude name
GEOADD cafes 15.087269 37.502669 "Catania"

# Distance between two locations (km, m, mi, ft)
GEODIST cafes "Palermo" "Catania" km    # "166.27"

# Find locations within radius
GEORADIUS cafes 15 37 100 km
# Returns ["Catania", "Palermo"]

# Get coordinates
GEOPOS cafes "Palermo"    # ["13.361389", "38.115556"]

# Get geohash string
GEOHASH cafes "Palermo"   # "sqc8b49rny0"

# GEORADIUSBYMEMBER — radius from existing member
GEORADIUSBYMEMBER cafes "Palermo" 200 km

Under the hood: Geospatial indexes are stored as Sorted Sets with geohash-encoded scores. This means you can also use ZSET commands on geospatial data.

Use cases: Find nearby restaurants, ride-hailing dispatch, location-based recommendations.

MIGRATE atomically moves a key from one Redis instance to another:

# Move key 'mykey' to another Redis instance
MIGRATE 192.168.1.50 6379 mykey 0 5000 COPY REPLACE

Arguments:

• host port — Target Redis instance
• key|"" — Key to migrate (or "" with KEYS)
• destination-db — Database index on target
• timeout — Timeout in ms
• COPY — Keep the key on the source (don’t delete)
• REPLACE — Replace key on target if it exists
• KEYS key [key ...] — Migrate multiple keys (Redis 3.0.6+)

How it works:

1. Source serializes the key (RDB format)
2. Sends data to target
3. Target acknowledges
4. Source deletes the key (unless COPY is specified)

Use case: Moving data between Redis instances, resharding in Cluster, zero-downtime data migration.

• DUMP key — Serializes the key’s value in Redis internal format (returns a binary string)
• RESTORE key ttl serialized-value — Creates a key from the serialized value

# On source server
DUMP user:42
# Returns: "\x00\x15user_data_here\x06\x00\x8f..."

# On target server (can be different Redis instance)
RESTORE user:42 0 "\x00\x15user_data_here\x06\x00\x8f..."
# TTL = 0 means no expiration (persistent key)

Use cases:

• Key-level migration — Move a single key without MIGRATE
• Backup specific keys — Dump important keys for safekeeping
• Copy between environments — Restore production data to staging

Limitations:

• RESTORE replaces existing keys (use REPLACE option)
• Format may differ between Redis versions (backward compatible within the same major version)
• Only works for a single key at a time

When Redis reaches the maxmemory limit:

1. Writes trigger eviction logic (reads still work fine)
2. Redis tries to evict keys based on the configured maxmemory-policy
3. If no keys can be evicted (noeviction policy) → write commands return an error

CONFIG SET maxmemory 1gb
CONFIG SET maxmemory-policy allkeys-lru

Commands that can fail when memory is full:

• All write commands (SET, LPUSH, SADD, HSET, etc.)
• EXPIRE (modifies TTL metadata)
• RENAME
• GETSET (modifies value)

Commands that still work:

• Read commands (GET, LRANGE, SMEMBERS, etc.)
• DEL (frees memory)
• UNLINK (non-blocking delete)
• FLUSHDB, FLUSHALL (clear all data)

Monitoring:

INFO stats
# evicted_keys: 1500    ← keys evicted since startup

A high or rapidly increasing evicted_keys count indicates the cache is too small or the eviction policy needs adjustment.

• DEL key — Synchronously deletes the key (blocks until memory is freed)
• UNLINK key — Asynchronously deletes (unlinks) the key (returns immediately)

DEL bigkey       # Blocks Redis for potentially seconds
UNLINK bigkey    # Returns immediately, freed in background

Why UNLINK exists:

• Deleting a key with a large value (e.g., a List with millions of elements) can block Redis for seconds
• UNLINK performs the O(1) unlinking part (removing from keyspace) immediately
• The actual memory reclamation (O(N)) happens in a background thread

When to use each:

• DEL — Small keys, or when you want deterministic behavior
• UNLINK — Large keys (> 10,000 elements), or when you must avoid blocking

In Redis 6+, FLUSHALL ASYNC and FLUSHDB ASYNC use the same background thread approach.

SCAN iterates over keys in the database incrementally without blocking Redis:

SCAN 0 MATCH user:* COUNT 100
# 1) "123"                      ← cursor for next call
# 2) 1) "user:42"               ← matching keys (up to 100)
#    2) "user:1001"
#    ...

SCAN 123 MATCH user:* COUNT 100  # Continue from cursor 123
# ... continues until cursor returns "0" (iteration complete)

Key points:

• Non-blocking — Only processes a small number of keys per call (unlike KEYS)
• Cursor-based — Returns a cursor to continue in the next call (cursor “0” = done)
• Not guaranteed to return all keys (keys added during iteration may be missed or duplicated)
• Each call guarantees about COUNT keys are checked (returned may be less)

Type-specific variants:

• SSCAN key cursor [MATCH] [COUNT] — Iterate Set members
• HSCAN key cursor [MATCH] [COUNT] — Iterate Hash fields
• ZSCAN key cursor [MATCH] [COUNT] — Iterate Sorted Set members

Always use SCAN instead of KEYS in production!

EVAL script numkeys key [key ...] arg [arg ...] executes a Lua script:

EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey "hello"

Key/arg convention:

• KEYS[1..N] — Redis keys (required for Cluster compatibility)
• ARGV[1..N] — Additional arguments (non-key values)

EVAL "
  local current = redis.call('GET', KEYS[1])
  if not current then
    redis.call('SET', KEYS[1], ARGV[1])
    return ARGV[1]
  end
  return current
" 1 mykey "default_value"

Why separate KEYS and ARGV?

1. In Redis Cluster, the hash slot is computed from keys — Redis needs to know which keys are used
2. Documentation clarity — easier to understand which are keys vs values
3. Redis can optimize command routing in Cluster

Available libraries in Redis Lua:

• redis.call() — Returns error on failure
• redis.pcall() — Returns error object on failure (catchable)
• redis.log() — Write to Redis log
• redis.sha1hex() — SHA1 hash
• redis.status_reply(), redis.error_reply() — Create responses

Instead of sending the full script source every time, you can load a script once and run it by its SHA1 hash:

# Load the script and get its SHA1 hash
SCRIPT LOAD "return redis.call('GET', KEYS[1])"
# Returns: "4e6d2e36c84283d7c9f8eef1e6f0e27c9f8eef12"

# Run by hash (much less bandwidth!)
EVALSHA 4e6d2e36c84283d7c9f8eef1e6f0e27c9f8eef12 1 mykey