Redis Patterns for Interview Systems

Redis shows up in more interview designs than almost any other component — but it's not a database. We use it for sub-millisecond reads, atomic counters, sorted-set rankings, and pub/sub fan-out.

Redis runs one command at a time per thread — match data structures to the operation you need:

Redis is more than a key-value cache — sorted sets, pub/sub, and atomic counters solve interview problems directly. Three lenses:

Walk Redis placement as interview steps. Step 1 — Session store: hash per user with TTL for stateless app servers. Step 2 — Rate limiting: sliding window counter or token bucket in a sorted set. Step 3 — Leaderboard: ZADD/ZRANGE on sorted sets for O(log n) rank queries. Step 4 — Pub/sub fan-out: publish events to channels for live updates. Step 5 — Persistence note: state whether RDB snapshots or AOF durability is required.

Each Redis data structure maps to a specific interview pattern — we cite the structure, not just "Redis":

• Strings & Atomic Flags: The base atomic key-value workspace:

• Sorted Sets (ZSET): Score-based ordering maps directly to:

• Streams (XADD/XREADGROUP): append-only consumer groups for lightweight event processing when Kafka is overkill.
• HyperLogLog (PFADD/PFCOUNT): ~12 KB per key for approximate unique counts (daily active users, unique visitors).
• Pub/Sub (PUBLISH/SUBSCRIBE): fire-and-forget fan-out for cache invalidation signals — no persistence; use Streams or an external broker when durability matters.

In-memory speed trades durability and memory cost — we state both sides:

Hot keys, memory eviction, and single-threaded CPU are Redis failure modes we volunteer:

These HLD problems map cleanly to specific Redis primitives:

• Sentinel vs Cluster Configuration: Structuring Redis high availability at scale:

Reach for Redis when sub-millisecond reads, atomic counters, or pub/sub fan-out are on the critical path:

Redis sits inside the broader caching, consistent hashing, and rate-limiting conversation:

• Caching Patterns & Invalidation: Using Redis as a transient read shielding tier.
• Message Queues Fundamentals: Using Redis Streams vs RabbitMQ/Kafka.
• Bloom Filter: Running probabilistic set lookups using Redis Bitmaps.

Atomic Transactions via Lua Scripting

To perform multi-step conditional updates without locking overhead (like verifying a user's rate limits and incrementing their requests count), execute **Lua scripts**. Redis guarantees that Lua scripts run atomically, preventing other threads from modifying the state in the middle of execution:

-- Atomic Rate Limit Check Lua
local current = redis.call('INCR', KEYS[1])
if current == 1 then
    redis.call('EXPIRE', KEYS[1], ARGV[1])
end
if current > tonumber(ARGV[2]) then
    return 0 -- Rejected
end
return 1 -- Allowed

Persistence Tuning: RDB vs AOF

Redis offers two models to sync memory state onto persistent disk storage:

1. RDB (Redis Database Backup): Periodic point-in-time snapshots (e.g. every 5 minutes). High recovery speeds, but crashes can cause minutes of data loss.
2. AOF (Append Only File): Log every write operation sequentially. Minimal data loss (fsync every 1s), but larger file footprints and slower reboot times.

**Production Best Practice**: Combine both! Use RDB snapshots for rapid disaster boots, and tail them with AOF lines to reconstruct missing transactions.

Redlock Controversy (Distributed Locks)

Redis SET key token NX EX ttl locks work for single-instance coordination. Redlock (multi-master quorum) was proposed for fault tolerance but is debated — clock drift and long GC pauses can violate safety. Interview signal: prefer a consensus store (etcd/ZooKeeper) for correctness-critical locks; use Redis locks with fencing tokens and short TTLs for best-effort coordination (rate limits, cron leaders).