Redis Common Patterns

# Step 1: Try to acquire the lock
SETNX my-lock "process-A"
# Returns 1 (success) — lock acquired

# Step 2: Set expiry so the lock doesn't live forever
EXPIRE my-lock 10

# THE PROBLEM:
# What if the process crashes BETWEEN Step 1 and Step 2?
# → SETNX succeeds (lock is held)
# → EXPIRE never runs (process died)
# → Lock is held FOREVER — deadlock
# → No other process can ever acquire it

# Acquire lock — atomic, no race condition
SET my-lock "process-A-uuid" NX EX 10
# NX  = only set if key does NOT exist (acquire)
# EX  = expire after 10 seconds (auto-release)
# Returns "OK" if acquired, nil if already held

# The value should be a unique identifier (UUID)
# so only the holder can release the lock

# Release lock — only if we still hold it
# (Must use Lua script for atomicity)
EVAL "
  if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
  else
    return 0
  end
" 1 my-lock "process-A-uuid"

Setup: 5 independent Redis instances (not replicas — independent)

Acquire lock:
  1. Record current time T1
  2. Try to acquire the lock on ALL 5 instances
     SET resource-lock uuid NX EX 30  (on each instance)
  3. Record current time T2
  4. Lock is acquired if:
     a. Majority (≥3 of 5) instances granted the lock
     b. Total time (T2 - T1) < lock TTL
        (if it took 29 seconds to acquire a 30-second lock,
         it's already almost expired — reject it)
  5. Effective lock validity = TTL - (T2 - T1)

Release lock:
  Send DEL (via Lua script) to ALL 5 instances
  (even ones that didn't grant the lock — cleanup)

Failure tolerance:
  → 2 of 5 instances can fail and the lock still works
  → No single point of failure

# Key format: rate_limit:{user_id}:{window}
# Window = current minute (e.g., 2024-01-15T10:30)

# For each incoming request:
key = "rate_limit:user123:2024-01-15T10:30"

INCR key
# First call: creates key with value 1 and returns 1
# Subsequent calls: increments and returns new value

# Set expiry only on first creation (when INCR returns 1)
EXPIRE key 60
# Key auto-deletes after 60 seconds

# Check the count
count = INCR key
if count > 100:
  # Rate limit exceeded — reject request (HTTP 429)
else:
  # Allow request

# Problem: boundary spike
# User sends 100 requests at 10:30:59 (end of window)
# User sends 100 requests at 10:31:01 (start of new window)
# → 200 requests in 2 seconds, but each window sees only 100

# For each incoming request:
key = "rate_limit:user123"
now = current_timestamp_ms()       # e.g., 1705312260000
window = 60000                     # 60 seconds in ms

# Step 1: Remove entries older than the window
ZREMRANGEBYSCORE key 0 (now - window)
# Removes all entries with score < (now - 60s)

# Step 2: Count entries in the current window
count = ZCOUNT key (now - window) now

# Step 3: If under limit, add this request
if count < 100:
  ZADD key now unique_request_id
  EXPIRE key 60                    # Cleanup: auto-delete if inactive
  # Allow request
else:
  # Rate limit exceeded — reject (HTTP 429)

# Why this works:
# The window "slides" with the current time
# No boundary problem — always looking at the last 60 seconds
# Trade-off: uses more memory (one entry per request)

-- Token bucket rate limiter (Lua script)
-- KEYS[1] = bucket key
-- ARGV[1] = max tokens (bucket capacity)
-- ARGV[2] = refill rate (tokens per second)
-- ARGV[3] = current timestamp (seconds)
-- ARGV[4] = tokens to consume (usually 1)

local key = KEYS[1]
local max_tokens = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

-- Get current state
local bucket = redis.call('HMGET', key, 'tokens', 'last_refill')
local tokens = tonumber(bucket[1]) or max_tokens
local last_refill = tonumber(bucket[2]) or now

-- Calculate tokens to add since last refill
local elapsed = now - last_refill
local new_tokens = elapsed * refill_rate
tokens = math.min(max_tokens, tokens + new_tokens)

-- Try to consume tokens
if tokens >= requested then
  tokens = tokens - requested
  redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
  redis.call('EXPIRE', key, max_tokens / refill_rate * 2)
  return 1  -- Allowed
else
  redis.call('HMSET', key, 'tokens', tokens, 'last_refill', now)
  redis.call('EXPIRE', key, max_tokens / refill_rate * 2)
  return 0  -- Rejected
end

# Read path
value = GET "user:42"
if value != nil:
  return deserialize(value)        # Cache HIT

# Cache MISS — load from database
value = db.query("SELECT * FROM users WHERE id = 42")
SET "user:42" serialize(value) EX 3600   # Cache for 1 hour
return value

# Write path — invalidate on update
db.query("UPDATE users SET name = 'Alice' WHERE id = 42")
DEL "user:42"                      # Invalidate cache
# Next read will load fresh data from DB

Write-Through:
  1. Application writes to cache: SET "user:42" new_data
  2. Cache layer synchronously writes to DB
  3. Both cache and DB are updated before returning to client
  → Pro: cache is always consistent with DB
  → Con: every write has double latency (cache + DB)

Write-Behind (Write-Back):
  1. Application writes to cache: SET "user:42" new_data
  2. Return success to client immediately
  3. Background worker flushes dirty cache entries to DB periodically
  → Pro: extremely fast writes (cache-speed)
  → Con: data loss risk if cache crashes before flush
  → Con: DB is temporarily stale

# Request arrives, cache miss on "product:42"

# Try to acquire rebuild lock
acquired = SET "lock:product:42" uuid NX EX 5
# NX = only if not exists, EX = 5 second timeout

if acquired:
  # I won the lock — rebuild cache
  data = db.query("SELECT * FROM products WHERE id = 42")
  SET "product:42" serialize(data) EX 3600
  DEL "lock:product:42"
  return data
else:
  # Someone else is rebuilding — wait and retry
  SLEEP 50ms
  value = GET "product:42"
  if value != nil:
    return deserialize(value)
  # Still not ready — retry (with backoff)

# Approach 1: Hash (individual fields)
HSET session:abc123 user_id 42
HSET session:abc123 email "alice@example.com"
HSET session:abc123 role "admin"
HSET session:abc123 cart_count 3
EXPIRE session:abc123 1800          # 30-minute TTL

# Read one field:
HGET session:abc123 role            # → "admin"

# Read all fields:
HGETALL session:abc123
# → user_id: 42, email: alice@example.com, role: admin, cart_count: 3

# Update one field without reading/writing the whole session:
HINCRBY session:abc123 cart_count 1

# ---

# Approach 2: Serialized string (JSON blob)
SET session:abc123 '{"user_id":42,"email":"alice@example.com","role":"admin","cart_count":3}' EX 1800

# Read: must deserialize the entire blob
GET session:abc123
# → parse JSON, extract what you need

# Update: must read, deserialize, modify, serialize, write back
# → NOT atomic without Lua

# Create session with 30-minute TTL
HSET session:abc123 user_id 42 email "alice@example.com"
EXPIRE session:abc123 1800

# On every request, refresh the TTL (sliding expiration)
EXPIRE session:abc123 1800
# → Session stays alive as long as the user is active
# → Expires 30 minutes after the LAST request

# Check remaining TTL
TTL session:abc123
# → 1742 (seconds remaining)

# Absolute expiration (session dies at a fixed time regardless)
EXPIREAT session:abc123 1705363200
# → Expires at this Unix timestamp, no matter what

# Add players with scores
ZADD leaderboard 1500 "alice"
ZADD leaderboard 2300 "bob"
ZADD leaderboard 1800 "charlie"
ZADD leaderboard 3100 "diana"
ZADD leaderboard 2750 "eve"

# Get top 5 players (highest scores first)
ZREVRANGE leaderboard 0 4 WITHSCORES
# → diana: 3100, eve: 2750, bob: 2300, charlie: 1800, alice: 1500

# Get a specific player's rank (0-indexed, highest first)
ZREVRANK leaderboard "bob"
# → 2 (3rd place, 0-indexed)

# Get a specific player's score
ZSCORE leaderboard "bob"
# → 2300

# Get players ranked 10th to 20th (paginated)
ZREVRANGE leaderboard 9 19 WITHSCORES

# Count total players
ZCARD leaderboard
# → 5

# Player "alice" scores 200 more points
ZINCRBY leaderboard 200 "alice"
# → 1700 (returns new score)
# The sorted set automatically re-ranks alice

# This is atomic — no read-modify-write race condition
# Even with 1000 concurrent score updates, every increment is applied

# Replace score entirely (ZADD overwrites)
ZADD leaderboard 5000 "alice"
# → alice now has score 5000, re-ranked to #1

# Conditional update: only if new score is higher (GT flag, Redis 6.2+)
ZADD leaderboard GT 4000 "alice"
# → Ignored because 4000 < 5000 (current score)

ZADD leaderboard GT 6000 "alice"
# → Updated to 6000 because 6000 > 5000

# Page size: 10 players per page

# Page 1 (ranks 1-10)
ZREVRANGE leaderboard 0 9 WITHSCORES

# Page 2 (ranks 11-20)
ZREVRANGE leaderboard 10 19 WITHSCORES

# Page 3 (ranks 21-30)
ZREVRANGE leaderboard 20 29 WITHSCORES

# Generic formula:
# Page N (1-indexed): ZREVRANGE leaderboard (N-1)*pageSize N*pageSize-1

# "Show me my neighborhood" — players around a specific rank
rank = ZREVRANK leaderboard "alice"    # e.g., 42
ZREVRANGE leaderboard (rank - 5) (rank + 5) WITHSCORES
# → Shows 11 players: 5 above alice, alice, 5 below alice

# Terminal 1 — Subscribe to a channel
SUBSCRIBE notifications
# Waiting for messages...

# Terminal 2 — Subscribe to the same channel
SUBSCRIBE notifications
# Waiting for messages...

# Terminal 3 — Publish a message
PUBLISH notifications "New order received: #12345"
# → (integer) 2  (delivered to 2 subscribers)

# Both Terminal 1 and Terminal 2 receive:
# 1) "message"
# 2) "notifications"
# 3) "New order received: #12345"

# Pattern-based subscription (PSUBSCRIBE)
PSUBSCRIBE orders.*
# Matches: orders.created, orders.shipped, orders.cancelled

PUBLISH orders.created '{"id": 123, "total": 59.99}'
PUBLISH orders.shipped '{"id": 120, "carrier": "FedEx"}'
# Both messages delivered to the pattern subscriber

# Goal: increment a counter only if it's below a limit
# Without Lua — race condition:

# Client A                          # Client B
GET counter  → 99                   GET counter  → 99
# 99 < 100, proceed                 # 99 < 100, proceed
INCR counter → 100                  INCR counter → 101  ← EXCEEDS LIMIT!

# Both clients read 99, both decide to increment
# Result: counter = 101, limit violated

-- Atomic check-and-increment (Lua script)
-- KEYS[1] = counter key
-- ARGV[1] = limit

local current = tonumber(redis.call('GET', KEYS[1]) or 0)
if current < tonumber(ARGV[1]) then
  return redis.call('INCR', KEYS[1])
else
  return -1  -- limit reached
end

-- Usage:
-- EVAL "..." 1 counter 100
-- This entire script runs atomically — no interleaving possible

# EVAL — send the full script every time
EVAL "return redis.call('GET', KEYS[1])" 1 mykey
# Works but sends the entire script text on every call

# EVALSHA — send only the script's SHA1 hash
# Step 1: Load the script (returns SHA1 hash)
SCRIPT LOAD "return redis.call('GET', KEYS[1])"
# → "a42059b356c875f0717db19a51f6aaa9161571a2"

# Step 2: Call by hash (much less bandwidth)
EVALSHA "a42059b356c875f0717db19a51f6aaa9161571a2" 1 mykey

# Redis caches loaded scripts in memory
# EVALSHA is preferred in production — less network overhead
# If the script isn't cached (server restart), fall back to EVAL

# Transfer 100 points from alice to bob — atomically
MULTI
DECRBY wallet:alice 100
INCRBY wallet:bob 100
EXEC
# Both commands execute atomically — no partial state visible
# Either both succeed or neither does

# IMPORTANT: You CANNOT do this with MULTI/EXEC:
MULTI
GET wallet:alice          # Returns "QUEUED", not the actual value!
# Can't check if alice has enough balance here
DECRBY wallet:alice 100   # Runs blindly
INCRBY wallet:bob 100
EXEC
# → No conditional logic possible inside MULTI/EXEC

# WATCH monitors keys for changes before EXEC
# If any watched key is modified by another client,
# EXEC returns nil (transaction aborted)

WATCH wallet:alice
balance = GET wallet:alice          # → 500

if balance >= 100:
  MULTI
  DECRBY wallet:alice 100
  INCRBY wallet:bob 100
  EXEC
  # If another client modified wallet:alice after WATCH,
  # EXEC returns nil — transaction aborted, retry
else:
  UNWATCH
  # Insufficient balance

# This is optimistic locking:
# → Assume no conflict, proceed optimistically
# → If conflict detected at EXEC time, abort and retry
# → Works well when conflicts are rare