Understanding Redis Data Types, Internal Representation, and Real‑World Use Cases

1. Is Redis data stored in memory?

Redis is an in‑memory database; most data resides in RAM and is periodically persisted to disk via append‑only files or snapshots, which gives it extremely fast read/write performance and makes it suitable for caching.

2. Common Redis data types and their usage scenarios

2.1 Redis common data types

The most frequently used Redis data structures are:

String

Hash

List

Set

Sorted Set

Pub/Sub

Transactions

Internally each key/value pair is represented by a redisObject that stores the type, encoding, and optional virtual‑memory (vm) flag.

2.2 Data‑type specific applications and implementation details

String

Common commands: SET, GET, INCR, DECR, MGET …

Use cases: Simple key/value storage, counters, and a drop‑in replacement for Memcached with persistence and replication.

Implementation: Stored as a raw string; when numeric operations are performed the encoding becomes int.

Hash

Common commands: HGET, HSET, HGETALL …

Use cases: Storing objects such as user profiles where individual fields need to be updated without rewriting the whole object.

Implementation: Small hashes use a compact zipmap encoding; larger ones automatically convert to a real hash table ( ht).

List

Common commands: LPUSH, RPUSH, LPOP, RPOP, LRANGE …

Use cases: Timelines, message queues, recent‑item feeds.

Implementation: Implemented as a doubly linked list, enabling fast push/pop at both ends.

Set

Common commands: SADD, SPOP, SMEMBERS, SUNION …

Use cases: Collections that must contain unique elements, e.g., follower lists, tag sets.

Implementation: Internally a hash table with NULL values, providing O(1) membership checks.

Sorted Set

Common commands: ZADD, ZRANGE, ZREM, ZCARD …

Use cases: Leaderboards, time‑ordered feeds, weighted queues.

Implementation: Combines a hash map (member → score) with a skip‑list for ordered traversal.

Pub/Sub

Provides a simple publish/subscribe messaging model; useful for real‑time chat, notifications, and event broadcasting.

Transactions

Allows grouping multiple commands with MULTI/EXEC; includes a WATCH mechanism for optimistic locking.

3. Practical Redis application patterns

3.1 Caching latest items

Store recent comment IDs in a list: LPUSH latest.comments <ID> Trim the list to keep only the newest N items: LTRIM latest.comments 0 5000 Retrieve a range, falling back to the relational database if the range exceeds the cached window:

FUNCTION get_latest_comments(start, num_items):
    id_list = redis.lrange("latest.comments", start, start+num_items-1)
    IF id_list.length < num_items
        id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
    END
    RETURN id_list
END

3.2 Leaderboards

Update scores with: ZADD leaderboard <score> <username> Get top‑N users: ZREVRANGE leaderboard 0 99 Get a specific user's rank:

ZRANK leaderboard <username>

3.3 Time‑based ranking (e.g., Reddit/Hacker News style)

Score formula: score = points / time^alpha Periodically recompute scores for the newest N items and store them in a sorted set.

3.4 Expiration handling

Use timestamps as scores; a background job removes entries whose score (time) is older than a TTL.

3.5 Counting and rate limiting

Atomic increments: INCR user:<id> EXPIRE user:<id> 60 Can be used to track page views, trigger banners, etc.

4. Additional patterns

Redis can also serve as a message queue (list push/pop with blocking variants), a Pub/Sub hub, and a fast cache that supersedes Memcached by offering persistence and richer data structures.

Overall, Redis’s in‑memory nature, rich command set, and multiple data types make it a versatile tool for caching, real‑time analytics, ranking, and many other backend scenarios.