Redis Patterns for Interview Systems – System Design Core Concept

What:

A high-performance, single-threaded in-memory key-value data store providing advanced data structures (Sorted Sets, Hashes, HyperLogLogs).

Primary purpose:

Achieving low-latency state coordination, rate limiting, and analytics lookups under extreme query scales.

Usually used for:

Distributed locking, sliding-window rate limiters, session caches, and leaderboards.

How should I think about this inside system architectures?

🧵 Single-Threaded Speed

Executes all commands sequentially in a single main thread, entirely eliminating multi-threaded race conditions.

📊 Rich Data Structures

Never treat Redis as a basic text-string bucket. Match sorted sets, bitmaps, or streams to specific computational requirements.

🔒 Atomic Lock Guards

Leverage atomic primitives like `SET NX` or Lua scripts to safely coordinate transactions across multiple application workers.

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

Use Case	Command Pattern	Why It Matters
Idempotency Keys	SETEX idempotency:txn_100 "processing" 3600	Preventing duplicate payments or processing runs
Distributed Locks	SET lock:resource token NX EX 30	Ensuring mutually exclusive task coordination

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

Use Case	Command Pattern	Why It Matters
Global Leaderboards	ZADD rankings score user_id	Retrieve rankings in $O(\log N)$ time
Sliding Window Rate Limiters	ZADD rate:user timestamp timestamp	Filter sliding windows atomically using epoch timestamps

Benefit	Cost
In-Memory Latency (executes operations in microsecond speeds by avoiding heavy disk context switches)	Memory Space Limits (RAM storage is highly expensive compared to SSD persistent blocks)
Atomicity via Single-Threading (avoids concurrency race conditions using serial commands)	Single-Core Blocking (O(N) operations like `KEYS` lock the entire engine thread for other clients)

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

Feature	Redis Sentinel	Redis Cluster
High Availability	Master-Replica with Sentinels for quorum failover	Hash-slotted shard replication (16384 total slots)
Optimal Scale Dataset	< 25 GB memory dataset (Single-node limits)	> 25 GB datasets (Distributed shard pools)

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:

LUA

-- 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:

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.
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.