Data Structures Interview Questions

STRING is the right pick when the whole blob is read and written together—session JSON, a rendered fragment, or a single counter. HASH wins when you need HGET or HSET on individual fields without rewriting the rest. Stuffing a 200-field profile into one STRING just because SET is familiar is a common interview miss.

A HASH is cheaper than N STRING keys for one object: one key, field-level updates, and listpack encoding while fields stay small. Keys such as user:1:name and user:1:email waste dict overhead and make EXPIRE clumsy because TTL is per key. Collapse them unless you truly need independent timeouts.

LIST gives O(1) LPUSH and RPOP but no consumer groups, no pending-entry list, and no durable cursor. It is fine for a simple FIFO or a bounded recent-items buffer. Once multiple workers must acknowledge jobs, STREAM with XREADGROUP is the type you want.

SET membership is O(1) and unique, so tags, exact unique-id collections, and SISMEMBER checks stay cheap. LIST allows duplicates and would need a linear walk to test membership. SINTER and SUNION are why SET shows up when the problem is relations rather than order.

ZSET ranks members by a floating score, so leaderboards, delayed jobs whose score is ready-at, and sliding time windows fall out of ZRANGEBYSCORE. SET has no order. Using ZSET only to store unique IDs wastes skiplist memory for no ranking benefit.

STREAM via XADD keeps an ID-ordered log, consumer groups, and XACK. LIST pops destroy the item, so a crashed worker loses the job. If you need replay or several consumer groups on the same log, STREAM is the log; LIST is only a stack or queue.

TTL from EXPIRE is per-key, not per HASH field. Expiring user:42 drops the entire HASH. For field-level lifetime you split keys or store a timestamp in the field and lazy-delete. PEXPIRE is the millisecond form; PERSIST removes the timeout.

SET with NX fails if the key already exists, which is how you implement a lock or a first-write-wins cache fill. XX updates only an existing key, useful when you want refresh-without-create. Pair NX with EX so a crashed holder cannot pin the key forever.

INCR is atomic on a STRING integer, so two clients cannot both read 9 and write 10. A GET/SET pair races. INCRBYFLOAT exists for floats; never mix INCR and INCRBYFLOAT on the same key. Combine the first increment with EXPIRE for a windowed rate counter.

SETBIT packs flags into a STRING at bit offsets, so daily-active bits for sequential integer ids stay tiny. A SET of millions of ids is far fatter. BITMAP fails when ids are sparse UUIDs because you allocate huge holes. BITCOUNT and BITOP AND are the usual analytics ops.

PFADD standard error is about 0.81 percent, so a count of one million can be off by thousands. That is fine for unique-IP dashboards, not for invoices. PFCOUNT is cheap for one key; merging many HLLs is heavier. Never treat HyperLogLog as exact.

listpack, formerly ziplist, packs small HASH, ZSET, and LIST values into a compact blob instead of a hashtable or skiplist. Crossing hash-max-listpack-entries or hash-max-listpack-value converts the key and RSS jumps. OBJECT ENCODING after a surprise memory increase is the check interviewers want.

GEOADD stores geohash scores inside a ZSET, so GEORADIUS or GEOSEARCH is a score-range walk plus haversine. You cannot mix arbitrary leaderboard scores with geo on the same key. For users-near-me this is enough; road-network routing does not belong in Redis.

Storing a JSON blob as one STRING means every field change is a full GET-modify-SET and a fatter network payload. HASH fields let you HSET one attribute. RedisJSON JSON.SET is the module path if you need path updates. Core Redis has no nested document type.

When a HASH outgrows hash-max-listpack-entries, Redis rewrites it as a hashtable and per-field overhead explodes. A key that was 8 KB can become tens of KB with the same data. Tune the thresholds or split the object instead of ignoring OBJECT ENCODING after growth.

A big key is a HASH, LIST, SET, ZSET, or STREAM with huge cardinality or huge values, not merely a long STRING. DEL, EXPIRE, and replica sync stall the single thread. Split with hash tags, use UNLINK for lazyfree deletes, and find offenders with MEMORY USAGE.

XTRIM with approximate MAXLEN or MINID deletes a range without a naive XDEL loop. Exact MAXLEN is slower. Pair XADD MAXLEN approximate with a retention policy; consumer groups do not auto-delete pending entries.

MEMORY USAGE paired with OBJECT ENCODING is the safe size-and-encoding check; DEBUG OBJECT is deprecated on some builds. Compare bytes before converting a HASH into STRING JSON. Cluster-safe introspection still must not use KEYS.

PFMERGE unions HyperLogLog sketches, so daily unique-user HLLs become a weekly estimate without storing raw ids. Error stays HLL error rather than a SUM of counts that double-counts. Keep source keys if you still need per-day numbers.

A BITMAP of sequential ints is dense and exact; a SET is exact for arbitrary strings but heavier; RedisBloom BF.ADD is probabilistic with a false-positive rate you choose. Billing cannot use Bloom. Interviewers want that false-positive sentence out loud.