Redis Is a Toolbox, Not a String Store: Pick the Structure That Fits the Access Pattern

Treating Redis as a string key-value store is the most expensive habit junior engineers carry into production. Each built-in structure exists because it maps cleanly to a recurring system design problem, and picking the wrong one shows up later as either a memory bill or a CPU profile you cannot explain.

A HASH is the right answer when you store an object and read fields independently. A shopping cart with thousands of line items does not need to be deserialized in full to update one quantity. A SORTED SET is for ordered data with a numeric score, which covers leaderboards, sliding-window rate limiters, and any time-series query of the form "give me the events between two timestamps." A BITMAP is the right tool for presence: one bit per user per day fits a year of daily-active tracking for a hundred million users in under five gigabytes. A HYPERLOGLOG answers cardinality questions in a fixed twelve kilobytes regardless of how many distinct items you insert, at the price of returning an approximate count with a small error. GEO is a thin layer over sorted sets that supports radius queries on latitude and longitude. A LIST is a serviceable lightweight queue when you do not need Streams semantics.

The production failure I keep seeing comes from defaulting to SORTED SET for anything that resembles a collection. One team I worked with tracked "active users today" by calling ZADD active_today <timestamp> <user_id> on every request. They reasoned that ZADD is O(log N) and that they could just call ZCARD for the count. By mid-afternoon the set held eighty million entries. The skiplist memory cost ran around eighty bytes per member, so the structure consumed several gigabytes for what should have been a single integer. ZADD and the periodic ZCARD showed up at the top of the CPU profile. The product question they needed to answer was the count, not the membership. PFADD with HyperLogLog answers the same question in twelve kilobytes flat and runs in effectively constant time. The data scientists never noticed the half-percent error.

The fix is a habit, not a refactor. Before you pick a structure, write down the access pattern. Do you need exact membership tests, ordered range queries, field-level updates, or just a count? Each of those points at a different command set and a different memory cost. The wrong choice still works on day one and gets more expensive every week after.