Core Data Types

Redis is not just a key-value store because its values are not just blobs. The keyspace maps names to data structures, and the data structure you choose determines which operations become natural, fast, and expressive.

The core types can be seen as a small set of shapes:

string     bytes
list       ordered sequence
hash       field-value map
set        unique unordered members
sorted set unique members ordered by score
stream     append-only log with IDs

The art of using Redis well is choosing the type that matches the access pattern, not the type that most closely resembles how the data looks in JSON.

Strings

Redis strings are binary-safe byte arrays. They are the simplest value type and the foundation for counters, tokens, cached payloads, locks, flags, and serialized application data.

SET session:7 abc
GET session:7
INCR pageviews
APPEND log-fragment "..."

Commands such as INCR interpret the stored bytes as an integer, but they do not change the logical type. A counter is still a string value with numeric operations layered on top.

Lists

Lists are ordered sequences optimized for operations near the ends.

LPUSH jobs email:1
RPOP jobs
LRANGE jobs 0 9

They are useful for stacks, simple queues, recent activity feeds, and workloads where pushing or popping from the left or right is the central operation.

A list is not a general query engine over ordered data. If ranking, scoring, or reliable delivery tracking becomes important, another Redis type may fit better.

Hashes

Hashes store field-value pairs inside a single Redis key:

HSET user:7 name Ada email ada@example.test
HGET user:7 name
HGETALL user:7

They are natural for objects with multiple fields. Instead of creating many top-level keys such as user:7:name and user:7:email, a hash groups related fields under user:7.

Small hashes can be stored compactly, which makes them more memory efficient than many separate keys in common cases.

Sets

Sets store unique members without ordering:

SADD online user:7
SISMEMBER online user:7
SINTER team:a team:b

They are ideal for membership questions, uniqueness, tags, relationship indexes, and intersections. If the primary question is "is this member present?" or "which members are shared?", sets are often the right shape.

Sorted Sets

Sorted sets add a score to each unique member:

ZADD leaderboard 100 ada
ZRANGE leaderboard 0 9 REV WITHSCORES

They support efficient access by rank and score. That makes them useful for leaderboards, priority queues, time-window indexes, rate limiting, and scheduling.

The subtle power of a sorted set is that it is both a dictionary and an ordered structure. Redis can find a member and also traverse members by score.

Streams

Streams are append-only logs with structured entries and IDs:

XADD orders * item book qty 1
XRANGE orders - +
XREAD STREAMS orders 0

They sit between simple queues and full messaging systems. A stream stores history, supports range queries, and can track delivery through consumer groups.

Pub/Sub broadcasts messages that vanish if nobody is listening. Lists can model simple queues. Streams are for replayable, ordered event data with more durable consumption semantics.

Type Choice Is System Design

Redis performance often comes from choosing the type that makes the desired operation cheap.

A user's profile may belong in a hash. A user's session token may be a string with a TTL. A list can hold recent notifications. A set can hold followers. A sorted set can rank posts by score. A stream can record events that multiple workers need to process reliably.

The same data can be modeled several ways. The right Redis model is the one that makes the workload's dominant questions easy to answer.