Redis Interview Questions — Core Concepts, Data Structures & Real-World Patterns

# Connect to Redis CLI
redis-cli

# ── STRING: Simple key-value with TTL (time-to-live) ──
SET user:1001:session_token "abc123xyz" EX 3600
# EX 3600 means this key auto-deletes after 1 hour
# Perfect for session tokens — no manual cleanup needed

GET user:1001:session_token
# Returns: "abc123xyz"

TTL user:1001:session_token
# Returns: 3598 (seconds remaining — live countdown)

# ── HASH: Store a user object without serializing to JSON ──
HSET user:1001 name "Priya Sharma" email "priya@example.com" plan "pro"
# Redis stores each field separately — you can update ONE field
# without reading and rewriting the whole object

HGET user:1001 plan
# Returns: "pro"

HGETALL user:1001
# Returns all fields: name, email, plan

# ── SORTED SET: Real-time leaderboard ──
ZADD game:leaderboard 9450 "alice"
ZADD game:leaderboard 8820 "bob"
ZADD game:leaderboard 9900 "carol"

# Top 3 players, highest score first (0-indexed range)
ZREVRANGE game:leaderboard 0 2 WITHSCORES
# Returns:
# 1) "carol"
# 2) "9900"
# 3) "alice"
# 4) "9450"
# 5) "bob"
# 6) "8820"

# ── LIST: Message queue pattern ──
LPUSH email:queue "welcome:user:1002"   # Push to the LEFT (head)
LPUSH email:queue "receipt:order:5501"
RPOP email:queue                        # Pop from the RIGHT (tail) — FIFO queue
# Returns: "welcome:user:1002"

# ── Check current persistence config ──
redis-cli CONFIG GET save
# Default output — snapshot triggers:
# 1) "save"
# 2) "3600 1 300 100 60 10000"
# Meaning: snapshot if 1 change in 3600s, OR 100 changes in 300s, OR 10000 changes in 60s

# ── Enable AOF (Append-Only File) for better durability ──
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG SET appendfsync everysec
# everysec = fsync every second — best balance of performance vs durability
# always  = fsync on every write — safest but ~10x slower
# no      = OS decides when to flush — fastest but data loss risk

# ── Set a memory limit and eviction policy ──
redis-cli CONFIG SET maxmemory 256mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
# allkeys-lru: when full, evict the least-recently-used key from ANY key
# volatile-lru: only evict keys that have a TTL — non-TTL keys are safe
# noeviction: reject new writes when full — returns OOM error (dangerous for a cache!)

# ── Simulate checking what would be evicted ──
redis-cli OBJECT IDLETIME user:1001:session_token
# Returns idle time in seconds — higher = more likely to be evicted under LRU

# ── Persist config changes to redis.conf so they survive restart ──
redis-cli CONFIG REWRITE
# Without this, all CONFIG SET changes are lost on restart!

# ── MULTI/EXEC: Batch commands atomically ──
redis-cli MULTI
redis-cli INCR order:5501:item_count
redis-cli EXPIRE order:5501:item_count 86400  # Set TTL inside the transaction
redis-cli EXEC
# Both commands execute atomically — no client can modify order:5501:item_count
# between INCR and EXPIRE

# ── Lua Script: Atomic rate limiter ──
# This is the CORRECT way to implement rate limiting.
# Using separate GET + INCR commands creates a race condition.

redis-cli EVAL "
  local key = KEYS[1]          -- e.g. 'ratelimit:user:1001:minute:2024010112'
  local limit = tonumber(ARGV[1])  -- e.g. 100 (requests per minute)
  local current = redis.call('GET', key)

  if current == false then
    -- Key doesn't exist yet — first request in this window
    redis.call('SET', key, 1, 'EX', 60)  -- Set count=1 with 60s TTL
    return {1, limit - 1}  -- {current_count, remaining}
  end

  current = tonumber(current)

  if current >= limit then
    return {current, 0}  -- Rate limit hit — reject the request
  end

  -- Under the limit — increment and return updated values
  local new_count = redis.call('INCR', key)
  return {new_count, limit - new_count}
" 1 "ratelimit:user:1001:minute:2024010112" 100

# Output on first call: 1) (integer) 1   2) (integer) 99
# Output on 100th call: 1) (integer) 100  2) (integer) 0
# Output on 101st call: 1) (integer) 100  2) (integer) 0  (blocked)

# ── WATCH: Optimistic locking (alternative to Lua for simple cases) ──
redis-cli WATCH user:1001:balance
# If user:1001:balance is modified by another client before EXEC,
# the entire transaction aborts and returns nil — your app retries
redis-cli MULTI
redis-cli DECRBY user:1001:balance 50
redis-cli EXEC
# Returns nil if balance was modified by another client (optimistic lock failed)
# Returns array of results if successful

# ── Check replication status ──
redis-cli INFO replication
# On primary node output includes:
# role:master
# connected_slaves:2
# slave0:ip=10.0.0.2,port=6379,state=online,offset=1234567,lag=0
# slave1:ip=10.0.0.3,port=6379,state=online,offset=1234560,lag=1
# replication_backlog_size:1048576

# ── Redis Cluster: Hash slot calculation ──
# Redis Cluster uses CRC16(key) % 16384 to decide which shard a key lives on
# Problem: these two keys land on DIFFERENT shards:
redis-cli CLUSTER KEYSLOT "user:1001:session"   # Returns e.g. 11543
redis-cli CLUSTER KEYSLOT "user:1001:profile"   # Returns e.g. 6452
# MGET user:1001:session user:1001:profile would FAIL in cluster mode!

# ── Solution: Hash Tags force keys to the same slot ──
# Wrap the shared part in curly braces — only the part in {} is hashed
redis-cli CLUSTER KEYSLOT "{user:1001}:session"   # Both hash on "user:1001"
redis-cli CLUSTER KEYSLOT "{user:1001}:profile"   # Same slot as above!
# Now MGET {user:1001}:session {user:1001}:profile works correctly

# ── Check cluster node topology ──
redis-cli CLUSTER NODES
# Output shows all nodes, their roles, and which hash slot ranges they own:
# a1b2c3... 10.0.0.1:6379 master - 0 1620000000000 1 connected 0-5460
# d4e5f6... 10.0.0.2:6379 master - 0 1620000000001 2 connected 5461-10922
# g7h8i9... 10.0.0.3:6379 master - 0 1620000000002 3 connected 10923-16383

# ── Check Sentinel state ──
redis-cli -p 26379 SENTINEL MASTERS  # Port 26379 is the default Sentinel port
# Shows the primary being monitored and its current state
# 'num-slaves': 2 — how many replicas exist
# 'num-other-sentinels': 2 — how many other Sentinel nodes are watching
# 'quorum': 2 — how many must agree to trigger failover