Redis (Remote Dictionary Server) Data Structures: Where and Why they are used

Redis is often introduced as an in-memory key-value store.

But calling Redis a simple key-value database misses one of its most important features: Redis provides a collection of specialized data structures, each designed for a different type of problem.

Instead of storing everything as a simple string:

key → value

Redis lets you work with strings, hashes, lists, sets, sorted sets, streams, and more.

Understanding these structures makes it much easier to understand why Redis is used for caching, queues, leaderboards, rate limiting, sessions, messaging, and event processing.

Strings — The Simplest Data Structure

The Redis String is the basic building block.

SET user:name "Muhammad"
GET user:name

Conceptually:

user:name
    ↓
"Muhammad"

Strings can contain text, numbers, serialized JSON, or even binary data.

They also support atomic operations:

INCR page_views
DECR stock

Where are they used?

Strings are commonly used for:

• Caching
• Counters
• Sessions
• Tokens
• Configuration
• Simple key-value data

For example:

API
 ↓
Redis
 ↓
cached response

A common pattern is:

GET cache
   ↓
Found? ── Yes → return
   │
   No
   ↓
Database
   ↓
Store in Redis

Hashes — Objects With Fields

Hashes are useful when you want to represent an object.

HSET user:123 name Muhammad age 22 role engineer

Conceptually:

user:123
 ├── name → Muhammad
 ├── age  → 22
 └── role → engineer

You can retrieve individual fields:

HGET user:123 name

or the entire object:

HGETALL user:123

Where are they used?

Hashes are useful for:

• User profiles
• Product information
• Configuration
• Session data
• Small objects

Instead of storing:

user:123:name
user:123:age
user:123:role

you can group those fields into one Redis Hash.

Lists — Ordered Collections

A Redis List is an ordered sequence of elements.

LPUSH jobs "job1"
LPUSH jobs "job2"
LPUSH jobs "job3"

Conceptually:

jobs

job3
 ↓
job2
 ↓
job1

You can add and remove elements from either end.

LPUSH
RPUSH
LPOP
RPOP

Where are they used?

Lists are useful for:

• Simple queues
• Task processing
• Recent activity
• Message buffers
• Ordered collections

For example:

              Redis
                │
        ┌───────┴───────┐
        │     jobs      │
        └───────┬───────┘
                │
                ↓
             Worker

A worker can take jobs from the list and process them.

For more sophisticated event processing, however, Redis Streams are usually a better fit.

Sets — Unique Values

A Redis Set is an unordered collection of unique values.

SADD online_users Ali
SADD online_users Ahmed
SADD online_users Ali

The second Ali isn't added because Sets don't allow duplicates.

Conceptually:

online_users
{ Ali, Ahmed }

Sets also support operations such as:

SINTER
SUNION
SDIFF

This makes them particularly useful when working with groups.

Where are they used?

Sets are commonly used for:

• Unique users
• Tags
• Permissions
• Membership
• Relationships
• Deduplication

For example:

user:123:permissions
{read, write, admin}

You can quickly check whether a value belongs to the set.

Sorted Sets — Values With Scores

Sorted Sets are one of Redis’s most powerful structures.

Get M. Ali Khan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Each member has a score.

ZADD leaderboard 950 Ali
ZADD leaderboard 870 Ahmed
ZADD leaderboard 810 Hamza

Conceptually:

leaderboard

Ali      → 950
Ahmed    → 870
Hamza    → 810

Redis keeps these members ordered by score.

You can then efficiently retrieve rankings or ranges.

Where are they used?

Sorted Sets are excellent for:

• Leaderboards
• Rankings
• Priority systems
• Scheduling
• Time-based data
• Top-N queries

For example:

Game Server
     │
     ↓
 Redis Sorted Set
     │
     ├── Ali   → 950
     ├── Ahmed → 870
     └── Hamza → 810

Redis doesn’t need to sort the entire collection every time you request the leaderboard.

Streams — An Event Log

Redis Streams are designed for append-only event data.

You can think of a Stream as a small event log:

orders

171234-0 → order.created
171235-0 → payment.completed
171236-0 → order.shipped

New events are appended to the stream.

Consumers can then process those events.

               Redis Stream
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
      Consumer A           Consumer B
       Workers              Analytics

Streams also support consumer groups, allowing multiple workers to divide the work.

Where are they used?

Streams are useful for:

• Event processing
• Background jobs
• Activity feeds
• Service-to-service events
• Asynchronous workflows

They are particularly useful when you need more durability and processing semantics than basic Pub/Sub.

Bitmaps — Working With Bits

Redis also provides Bitmaps.

Instead of storing individual values, you manipulate individual bits.

For example:

00010110

Each position represents a boolean state.

Where are they used?

Bitmaps can be useful for:

• Feature flags
• User activity
• Presence tracking
• Large-scale boolean datasets

They’re especially useful when you have millions of yes/no values and want to represent them compactly.

HyperLogLog — Approximate Counting

Sometimes you don’t need the exact number of unique users.

You just need an efficient estimate.

That’s where HyperLogLog comes in.

For example:

PFADD visitors user1
PFADD visitors user2
PFADD visitors user3
PFCOUNT visitors

It estimates the number of unique elements while using very little memory.

Where is it used?

Common examples include:

• Unique visitors
• Analytics
• Traffic measurement
• Approximate cardinality

The trade-off is important:

HyperLogLog
     ↓
Very low memory
     ↓
Approximate result

Choosing the Right Data Structure

The easiest way to remember Redis structures is to think about the problem you’re solving.

The Bigger Picture

The real power of Redis isn’t simply that it stores data in RAM.

It’s that Redis gives applications specialized data structures with operations designed around them.

Instead of doing:

Store everything
      ↓
Fetch everything
      ↓
Process everything
      ↓
Sort/filter in application

you can choose a structure that matches the problem:

Cache          → String
Object         → Hash
Queue          → List
Unique values  → Set
Ranking        → Sorted Set
Events         → Stream
Boolean states → Bitmap
Approx. counts → HyperLogLog

That’s the key idea behind Redis:

Don’t just store data. Choose a data structure that makes the operation you need cheap.

Once you understand that principle, Redis stops looking like a simple cache and starts looking more like what it really is: a collection of highly optimized data structures exposed through a network server.

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here.