0% completed
1.3 Redis Is a Data Structure Server
On This Page
Key-Value Store Versus Data Structure Server
The Opaque Value Problem
The Server-Side Alternative
Benefits of the Model
A Tour of the Structures
Strings
Hashes
Lists
Sets
Sorted Sets
Streams
Bitmaps and Bitfields
HyperLogLog
Geospatial Indexes
Pub/Sub
JSON, Search, Vectors and Probabilistic Types
Using This in an Interview
FAQs
Key Takeaways
A plain key-value store treats each value as an opaque blob of bytes: it stores the bytes and returns them, and it knows nothing about what they mean. Most developers first meet Redis in that role, as a cache where you put a string in, get a string out and set a time to live. That description is accurate, but it misses why Redis is used far beyond caching. Salvatore Sanfilippo, who created Redis, described it as a data structure server, and that phrase explains the difference.
Suppose a value in a plain store holds a list and you want to add one item. You read the whole blob, deserialize it, modify it, serialize it and write it back, and you hope that no other client changed it in between. In Redis, the value is a real data structure that lives inside the server, and the server understands its type. You tell Redis "push this onto that list" or "add this member to that sorted set with this score", and the server performs the operation directly and atomically in memory.
This shift moves work from your application to the database. It removes whole classes of race conditions and cuts network traffic to a small fraction. Instead of moving the data to your code, you move the operation to the data.
Key-Value Store Versus Data Structure Server
The Opaque Value Problem
Consider a game leaderboard for one season, stored in a plain key-value store as one serialized list of players and scores. To record a new score, a game server fetches the entire list, parses it, updates one entry, sorts it, serializes it and stores it again. Two game servers doing this at the same time can overwrite each other's updates, so one score is lost. The cost also grows with the size of the list: with 100,000 players, every update moves the whole leaderboard across the network twice.
The Server-Side Alternative
In Redis, the same leaderboard is a sorted set, a collection of unique members that each carry a numeric score and are kept in score order. Recording a score is one command that updates one member in logarithmic time. Fetching the top three is one command that returns three entries, and getting a player's rank is one more command:
127.0.0.1:6379> ZADD leaderboard:season7 1200 alice 950 bob 1430 carol (integer) 3 127.0.0.1:6379> ZINCRBY leaderboard:season7 300 bob "1250" 127.0.0.1:6379> ZRANGE leaderboard:season7 0 2 REV WITHSCORES 1) "carol" 2) "1430" 3) "bob" 4) "1250" 5) "alice" 6) "1200" 127.0.0.1:6379> ZREVRANK leaderboard:season7 bob (integer) 1
ZADD replies with the number of new members it added, and ZREVRANK counts ranks from 0 at the highest score, so bob is second. Nothing large crosses the network. Two game servers that update scores at the same time cannot corrupt each other, because Redis executes commands one at a time, as the lesson Why Redis Is Fast explained.
Benefits of the Model
Three benefits follow from the model. Operations are atomic, because the server applies each command completely before it starts the next one. Network cost drops, because you send small commands and receive small results instead of shipping entire collections. Correctness also becomes simpler, because tested data structure code in the server replaces custom read-modify-write logic in every application.
The choice of structure also sets the performance. The right structure makes an operation constant time or logarithmic time, while the wrong one forces you into linear scans. Storing the leaderboard as a string costs O(N) per update, while the sorted set costs O(log N).
A Tour of the Structures
The chapter that follows this one covers each structure in its own lesson. This tour gives the purpose of each one and the problem it solves.
Strings
A string is the basic type, and it holds text, numbers or raw bytes up to 512 MB. Beyond simple caching, strings support atomic counters through INCR, which suits page views, rate limit counters and ID generation. SET with the NX option writes a value only if the key does not exist yet, which is the building block for simple locks. Strings also support bit operations and operations on byte ranges.
Hashes
A hash is a map of fields to values under one key, which fits an object such as a user profile with name, email and plan as fields. You can read or update a single field without touching the others, and you can increment numeric fields atomically. Small hashes use a compact encoding, so storing many small objects as hashes uses much less memory than storing each field as a separate key. Since Redis 7.4, individual fields can also have their own expiration time (HEXPIRE and related commands), so one field can expire while the rest of the hash stays.
Lists
A list is an ordered sequence that supports pushes and pops at both ends in constant time. Lists model queues, stacks, recent activity feeds and capped logs, which you keep short by trimming. Blocking pops such as BRPOP let a consumer wait for work without polling, which gives simple job queues. LMOVE and its blocking form BLMOVE move an item atomically from one list to another, so a worker can claim a job and the job can be recovered if the worker dies. They replace RPOPLPUSH and BRPOPLPUSH, which are deprecated since Redis 6.2.
Sets
A set is an unordered collection of unique members with constant-time add, remove and membership checks. Sets remove duplicates automatically and support union, intersection and difference on the server. A question such as "which users follow both A and B" or "which tags do these two articles share" therefore becomes one command rather than a loop in the application.
Sorted Sets
A sorted set keeps unique members ordered by score, as the leaderboard example showed. It supports range queries by rank or by score, rank lookup and atomic score increments. Each of these takes logarithmic time, and a range query adds time in proportion to the number of entries it returns, O(log N + M). Sorted sets serve leaderboards, priority queues, scheduling by timestamp, time-window data such as sliding window rate limiters, and autocomplete through lexicographic (alphabetical) ordering. For range queries, use ZRANGE with the BYSCORE, BYLEX and REV options, which replaced ZRANGEBYSCORE, ZRANGEBYLEX and ZREVRANGE in Redis 6.2. Because one structure covers so many of these needs, many engineers consider the sorted set the most versatile type in Redis.
Streams
A stream is an append-only log of entries, each with a time-ordered ID that Redis can generate. Streams support consumer groups, in which several workers share one stream and each entry goes to one worker. The worker acknowledges each entry it finishes, and entries that a failed worker received but never acknowledged can be claimed by another worker. This gives durable message passing and event logs inside Redis, similar in purpose to a small, single-server Kafka.
Bitmaps and Bitfields
A bitmap is a string treated as an array of bits, where bit number N stores a yes or no answer for the user with ID N. Tracking daily active users among 100 million IDs takes 100 million bits, which is 12.5 MB per day. Bit counting and bitwise operations across several bitmaps answer questions such as "which users were active on all seven days" at low cost. Bitfields extend the same idea to small integers packed into one string, with any width up to 64 bits for signed integers and up to 63 bits for unsigned ones.
HyperLogLog
A HyperLogLog is a probabilistic structure that estimates the number of distinct elements in a fixed amount of memory: at most 12 KB per key, with a standard error of 0.81 percent. It answers "how many unique visitors did this page have" without storing the visitors. It gives up exact counts in exchange for very large savings in space.
Geospatial Indexes
Geospatial commands store longitude and latitude pairs inside a sorted set. GEOADD adds a location, GEOSEARCH finds members within a radius or a box around a point, and GEODIST computes the distance between two members. These commands support nearby search and delivery tracking. GEOSEARCH replaced GEORADIUS and GEORADIUSBYMEMBER, which are deprecated since Redis 6.2.
Pub/Sub
With Pub/Sub, publishers send messages to named channels, and every subscriber connected to a channel receives them immediately. Redis stores nothing, so a subscriber that is offline misses the message. Pub/Sub suits live notifications and cache invalidation signals, while streams suit cases that need durability. Since Redis 7.0, sharded Pub/Sub (SPUBLISH and SSUBSCRIBE) binds each channel to one shard of a cluster instead of broadcasting every message to every node.
JSON, Search, Vectors and Probabilistic Types
Redis Open Source 8 builds several more types into every distribution. It includes JSON documents, the Query Engine for secondary indexes, full-text search and vector similarity search, time series, and five probabilistic types: Bloom filter, Cuckoo filter, Count-min sketch, Top-k and t-digest. Before Redis 8, these came as separate modules or bundled as Redis Stack, which Redis no longer patches. Redis 8.0 also introduced vector sets, a native type for vector similarity, as a beta feature. Valkey and Redis versions before 8 do not include these types in the core server. All of them follow the same idea: put a specialized structure and its operations inside the server.
Using This in an Interview
Say that Redis keeps real data structures on the server and exposes operations on them, so the work moves to the data, each operation is atomic and network traffic stays small. Then name the structure for each requirement: sorted sets for rankings and time windows, lists or streams for queues, hashes for objects, sets for uniqueness, and HyperLogLog or bitmaps for compact counting.
Why is a sorted set better than a serialized list for a leaderboard? An update changes one member on the server in O(log N), instead of moving and sorting the whole list in the application.
When does Pub/Sub fit instead of a stream? When a missed message is acceptable, because Pub/Sub stores nothing, while a stream keeps its entries for consumer groups to read and acknowledge.
FAQs
What is the difference between a key-value store and a data structure server?
A key-value store treats values as opaque bytes, so changing one means reading, modifying and rewriting the whole value in your application. A data structure server understands the type of each value and exposes operations on it, so the server performs the change directly and atomically.
Which Redis structure should I use for a leaderboard?
Use a sorted set. Scores are updated atomically, ranges and ranks are retrieved in logarithmic time, and no sorting happens in the application.
When should I use a hash instead of separate string keys?
Use a hash when the data is one object with several fields. Hashes let you read or update individual fields, keep related data under one key, and use a compact encoding for small objects, which saves a lot of memory at scale.
List, stream or Pub/Sub for messaging?
Use Pub/Sub for live broadcast where a missed message is acceptable. Use lists for simple queues with one pool of workers. Use streams when you need persistence, consumer groups, acknowledgment and replay.
Key Takeaways
- Redis values are data structures the server understands. You send operations to the data rather than pulling the data into your code.
- Pick the structure by access pattern. Strings for counters, hashes for objects, lists for queues and feeds, sets for uniqueness, sorted sets for rankings and time windows, streams for durable messaging.
- Use the current commands. LMOVE, GEOSEARCH and ZRANGE with BYSCORE or REV replace their deprecated predecessors.
- Redis 8 builds in more types. JSON, the Query Engine, time series and probabilistic filters ship in Redis Open Source 8 without separate modules.
Reading Progress
0%
On This Page
Key-Value Store Versus Data Structure Server
The Opaque Value Problem
The Server-Side Alternative
Benefits of the Model
A Tour of the Structures
Strings
Hashes
Lists
Sets
Sorted Sets
Streams
Bitmaps and Bitfields
HyperLogLog
Geospatial Indexes
Pub/Sub
JSON, Search, Vectors and Probabilistic Types
Using This in an Interview
FAQs
Key Takeaways