Stop 2 · Data structures in depth
Every structure a value can hold, taken one at a time: mental model + commands + uses + encoding + interview probes
First, a common misunderstanding: Redis does not only store strings
Many people think Redis is a store that only holds strings. More precisely: a key is always a string, and it is the value that has a type. Redis is called a "data structure server", not just a cache, because a value can be one of several structures, and each structure has its own set of commands. The tabs below take them one at a time. For each one: how to think about it, the commands you will actually use, real uses, the , and the questions an interviewer asks next.
The most basic type, and the one you will use most. One key holds one value. The name is misleading: the value can also be a number, and Redis has INCR and DECR that change it in place, so you do not have to read the value, add one, and write it back. A value can also be a whole JSON document or binary data. GET and SET are both O(1).
SET name "Wayne"store a valueGET nameread by keySET otp 123456 EX 30store with a 30s TTLINCR page:viewsatomic +1 (counter)SET lock v NX EX 10write only if the key is absent (claim / idempotency)MGET k1 k2 k3read several keys in one round trip
- cache one whole result, such as an aggregated JSON document
- counters: page views, rate-limit counts, failed attempts
- flags, feature toggles, one-time codes, session tokens
- distributed locks and idempotency claims (SET with NX and a TTL)
All three Redis uses in our system are Strings: the rate quote stored as a JSON string, the idempotency key, and the balance projection. One type covers a lot of ordinary work.
Three encodings: int (a value that is an integer is stored as an integer, which uses the least memory), embstr (strings of 44 bytes or fewer, allocated in one block together with the object header), raw (longer strings, allocated separately). Redis picks one for you.
Because INCR is . GET then SET is two steps: two clients can read the same old value, each add one, and write back, so one increment is lost. INCR does the read and the write inside a single command, and Redis executes commands one at a time, so no other client can slip in between.
The limit is 512MB. In practice keep values far below that. A command on a very large value holds the execution thread for as long as it runs, and every other request waits behind it (see the "big key" probe).
General probes: these come up whatever structure you choose
A key whose value is very large: a String of several MB, or a list, set, or sorted set with hundreds of thousands of members. Redis , so an O(n) command on such a key — HGETALL, SINTER on a large set, DEL on a huge collection — holds the execution thread for as long as it takes, and every other request waits. Split large keys into smaller ones, read them in batches with cursor commands such as SCAN and HSCAN instead of fetching everything at once, and delete large collections with UNLINK instead of DEL so a background thread frees the memory.
Most commands are O(1) or O(log n) and the data is already in memory, so a single command finishes in microseconds, and running them one at a time also removes the cost of locking (the Stop 1 point). One clarification on "single-threaded": since Redis 6, extra threads can read and write network sockets, but commands are still executed one at a time. The risk is the slow ones. KEYS scans the whole keyspace, so it is O(n) and blocks the server until it finishes. A very wide ZRANGE has to return m elements, and an O(n) command on a big key is slow for the same reason. In production use SCAN instead of KEYS: it returns a cursor and one batch at a time and does not block, at the price of possibly returning the same key twice and never giving a consistent snapshot of the keyspace. Break heavy work into smaller commands, or move it out of Redis.
Ask three questions. (1) The read and write shape: reading and writing the whole object points to a String; frequent edits to single fields point to a Hash. (2) Do you need order or ranking? Then a Sorted Set. (3) Do you need uniqueness or set operations? Then a Set. After that the specialized types: a counter is a String with INCR; a queue whose messages must not be lost is a Stream; one boolean per id, when the ids are dense, is a Bitmap; a distinct count you can afford to approximate is a HyperLogLog.