Mastering Redis: Choosing the Right Data Structure for High‑Performance Systems

1. String

Core features

Binary safe

Maximum size 512 MB

Atomic counters (INCR / DECR)

Typical architectural use cases

Hot cache – shortest access path

Distributed counter – atomic increment

Distributed lock – SET NX PX Rate limiting – simple and fast

Session storage – O(1) access

Production‑grade distributed lock example

SET lock:order:123 uuid NX PX 30000
-- Unlock Lua (prevent accidental delete)
if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
end
return 0

Anti‑patterns

Storing an entire JSON object in a String

Frequent updates of a single field inside JSON

Using oversized values (>10 KB) as a norm

2. Hash

Why Hash is preferred for object caching

Field‑level updates

Field‑level atomic counters

Memory compression (ziplist / listpack)

HSET user:1001 name "张三" age 25 city "北京"
HINCRBY user:1001 login_count 1

Typical business modeling

User object

key: user:{uid}
field: name / age / status / score

Shopping cart

key: cart:{uid}
field: productId
value: quantity

Anti‑pattern warnings

Hash is not a relational‑database table

Thousands of fields create a “big key” risk

Unsuitable for deeply nested structures

3. List

Lightweight message‑queue pattern

LPUSH queue:order order123
BRPOP queue:order 0

Latest‑list (feed) pattern

LPUSH feed:user:1001 postId
LTRIM feed:user:1001 0 99

Limitations as a true MQ

No ACK mechanism

No retry support

No consumption progress tracking

Message disappears after POP

4. Set

Social relationship modeling

SADD follow:1001 1002 1003
SADD follow:1002 1003 1004
SINTER follow:1001 follow:1002

High‑performance deduplication

SISMEMBER blacklist:ip 1.1.1.1

Architectural considerations

SMEMBERS

can become a memory bomb for large sets

Iterate large sets with

SSCAN

5. ZSet

Leaderboard core model

ZINCRBY live:rank:20231001 5 anchor:123
ZREVRANGE live:rank:20231001 0 9 WITHSCORES

Delay queue (classic design)

ZADD delay:queue 1700000000 task123
ZRANGEBYSCORE delay:queue 0 now LIMIT 0 1

Performance characteristics

Write: O(log N)

Read Top N: O(log N + M)

Lock‑free, atomic operations

6. Production case: latency reduction from 800 ms to 50 ms

7. Selection guidelines

String – minimal values or counters; switch to Hash when JSON fields are updated frequently.

Hash – object‑like data; switch when field count exceeds a few hundred.

List – ordered streams; switch when reliable consumption is required.

Set – deduplication or relational queries; switch when ordering is needed.

ZSet – ranking or time‑based queues; switch when a score is unnecessary.

8. Decision checklist

Access pattern

Update granularity

Need for ordering

Potential key explosion

Feasibility of atomic operations for concurrency control