A Complete Guide to Redis Data Structures — String, Hash, List, Set, ZSet

## String — Basic Key-Value

SET user:1:name "Hoon"
SET counter 0
INCR counter          # Atomic increment -> 1
INCRBY counter 10     # -> 11
EXPIRE user:1:name 3600  # TTL of 1 hour
TTL user:1:name       # Check remaining time

Use cases: sessions, counters, cache

Hash — Object Storage

HSET user:1 name "Hoon" email "hoon@test.com" age 30
HGET user:1 name       # "Hoon"
HGETALL user:1         # All fields
HDEL user:1 age        # Delete a specific field

Use cases: user profiles, configuration values

List — Ordered Collection

RPUSH notifications "메시지1" "메시지2"  # Push to the right
LPUSH notifications "메시지0"            # Push to the left
LRANGE notifications 0 -1               # Read all
LPOP notifications                       # Pop from the left
LLEN notifications                       # Length

Use cases: recent activity lists, message queues, activity feeds

Set — Unique Members

SADD tags:post:1 "vue" "javascript" "frontend"
SMEMBERS tags:post:1      # Read all
SISMEMBER tags:post:1 "vue"  # Check existence -> 1
SUNION tags:post:1 tags:post:2   # Union
SINTER tags:post:1 tags:post:2   # Intersection

Use cases: likes, followers, tags

Sorted Set — Score-Based Ordering

ZADD leaderboard 1500 "user:1"
ZADD leaderboard 2000 "user:2"
ZADD leaderboard 1800 "user:3"

ZREVRANGE leaderboard 0 9 WITHSCORES  # Top 10
ZRANK leaderboard "user:1"            # Rank (starts at 0)
ZINCRBY leaderboard 100 "user:1"      # Increase score

Use cases: real-time rankings, priority queues

Distributed Lock

# SET NX EX - acquire the lock atomically
SET lock:resource "lock-value" NX EX 30
# NX: set only when the key does not exist
# EX 30: release automatically after 30 seconds

// Using Redisson (Java)
RLock lock = redissonClient.getLock("lock:order:" + orderId);
if (lock.tryLock(5, 30, TimeUnit.SECONDS)) {
    try {
        // Critical section
    } finally {
        lock.unlock();
    }
}

What Gets Hard in Production

Redis data structures are valuable because they encode intent, but they also make it easy to hide durability and consistency assumptions.
The wrong structure choice often shows up first as operational pain, not as API inconvenience.
Memory growth, eviction policy, and persistence mode matter as much as command choice.

Architecture Decisions That Matter

Choose the structure based on access pattern, cardinality, ordering needs, and expiration semantics.
Decide whether Redis is cache, coordination layer, queue, or primary low-latency store for that data.
Align persistence and eviction policy with the business cost of data loss.

Practical Example

Different structures match different workload promises:

String -> simple cache value
Hash -> user/session attributes
List/Stream -> ordered work items
Set -> membership check
Sorted Set -> ranking and score-based ordering

Anti-Patterns to Avoid

Using Redis as a generic dump of mutable objects.
Ignoring key expiration strategy and ending up with accidental permanent data.
Building critical workflows on Redis without defining persistence and replay expectations.

Operational Checklist

Review memory usage by key pattern.
Validate eviction policy against production traffic spikes.
Document ownership of key naming and TTL rules.
Test persistence recovery if data matters beyond cache convenience.

Final Judgment

Redis works best when each structure is chosen with operational intent. If the data model is vague, the runtime behavior becomes vague too.

🗄️ Database

A Guide to MongoDB Schema Design

This post explains MongoDB schema design from a practical perspective, going beyond embedding-vs-reference comparisons to cover access patterns, document boundaries, indexes, aggregations, and transaction cost.

🗄️ Database

A Practical Guide to Elasticsearch

This post explains Elasticsearch from a practical engineering perspective: search design, mappings, analyzers, aggregations, and operational cost, rather than just installation and query examples.

📈 Trends

PostgreSQL 18 Trends: What Actually Matters in Practice

PostgreSQL 18 is more than an upgrade headline. AIO, skip scan, better post-upgrade recovery, OAuth, and generated columns all point to a release focused on operational cost reduction.

⚙️ Backend

A Practical Guide to Spring Boot and Redis Caching Strategies

This guide goes beyond @Cacheable and focuses on TTL design, invalidation, hot keys, consistency tradeoffs, and the metrics needed to run Redis caching well in production.

Turn AI service development and operations into one improvement loop