Redis data structures for caching — beyond simple key-value

A plain string value (often a serialized JSON blob, as in System Design's cache-aside example) is the simplest case — fine for caching a whole object as one unit. The problem appears the moment only part of that object needs updating: changing plan means reading the whole JSON blob, deserializing it, modifying one field, re-serializing, and writing the whole thing back — wasteful, and a real race condition if two requests do this concurrently.

A hash stores multiple named fields under one key, letting the application read or write a single field directly — no round trip through the entire object. This is the right structure whenever a cached entity has several fields that get updated independently, which a single-string cache entry forces into an all-or-nothing read-modify-write cycle every time.

A sorted set keeps every member ordered by a numeric score, with all of the above operations running in logarithmic time even with millions of members. Caching a leaderboard, a trending-items list, or a rate-limiter's sliding window (each member's score is a timestamp) as a sorted set means "give me the top 10" or "what's this user's current rank" never requires fetching everything and sorting it in application code — exactly the kind of computation worth pushing into the cache layer rather than repeating on every request.

A list (an ordered sequence, with fast push/pop from either end) fits a "most recent 20 items" cache — push new items to the front, trim the tail past 20, and the cache never grows unbounded. A set (unordered, unique members) fits fast membership checks — "has this user already seen this notification" as SISMEMBER is a single O(1) operation, versus scanning a list or deserializing a JSON array to check for one value.

The throughline across all four: a plain string forces every operation into "read everything, do the work in application code, write everything back." Each specialized structure exists because some specific operation — partial update, ranked retrieval, membership check, bounded recent-items — is common enough in real caching workloads to deserve its own purpose-built, efficient primitive rather than being reimplemented in application code on top of a generic blob every time.