When storing an object in Redis, what do you gain and lose by modelling it as a hash with one field per attribute versus serialising the whole object to JSON and storing it in a single string key?

## The two shapes ``` # hash HSET user:42 name Ada plan pro logins 3 # JSON in a string SET user:42 '{"name":"Ada","plan":"pro","logins":3}' ``` Both are one key. The difference is whether Redis can see inside it. ## What a hash gives you **Partial reads.** `HGET user:42 plan` or `HMGET user:42 name plan` returns just those bytes. On a wide object accessed on a hot path, this is the difference between shipping 40 bytes and shipping 4 KB per request — and it removes the client-side JSON parse too, which is often the larger cost. **Partial writes, and therefore concurrency.** `HSET user:42 plan pro` writes one field. A concurrent `HSET user:42 email …` writes a different field. Both land; neither clobbers the other. With JSON, each writer read the whole document before editing, so the second `SET` silently discards the first writer's change — the classic lost update. **Server-side field operations.** `HINCRBY user:42 logins 1` is a single atomic command. The JSON equivalent is read, parse, increment, serialise, write — three round trips, a race, and a need for `WATCH` or Lua to be correct. **Memory efficiency at small sizes.** A hash below the configured entry/value thresholds is stored in one compact flat structure rather than a hash table, which makes many small objects far cheaper than one key per attribute, and competitive with (often better than) a JSON blob whose keys are repeated as text in every value. **Introspection.** `HLEN`, `HEXISTS`, `HKEYS`, `HSTRLEN`, `HSCAN` and `HRANDFIELD` all work because Redis understands the structure. A JSON string is opaque bytes; the server can tell you its length and nothing else. **Per-field TTL** (Redis 7.4+). `HEXPIRE` can expire individual fields — impossible for attributes inside a serialised blob. ## What a JSON string gives you **Atomic whole-object semantics.** `SET` replaces the document in one step, so readers never observe a half-updated object. With a hash, a multi-field `HSET` is atomic, but two separate `HSET` calls are not — a reader between them sees a mixed state unless you wrap them in `MULTI`/`EXEC` or a script. **Nesting and types.** JSON has arrays, sub-objects, booleans, nulls and numbers. Hash fields and values are flat byte strings, full stop. Modelling `user.addresses[0].city` in a hash means either flattening (`addresses.0.city`) — which makes list mutation awkward — or serialising the sub-tree into one field, which is JSON-in-a-hash and loses the very partial-access benefit you chose the hash for. **One round trip, one codec.** `GET` + your existing serializer (JSON, MessagePack, protobuf) reuses the same object mapper the rest of your stack already uses, including schema evolution rules. Hashes force a hand-written mapping from your object to string fields, with explicit handling for absent fields, type coercion, and `null` versus empty string. **Compression.** A blob can be gzip'd or stored in a compact binary codec, which for large documents can beat a hash by a wide margin. Hash field names, by contrast, are stored per hash — 500,000 objects with a field literally named `last_login_timestamp` pay for that string half a million times. **Simpler versioning.** Embedding a `"v":3` in the document and migrating on read is a well-trodden pattern; the hash analogue is a `_v` field plus per-field migration logic. ## The decision Choose a **hash** when: - attributes are read or written independently (profile field edits, feature flags, session attributes); - you need atomic per-field counters (`HINCRBY`); - objects are small, numerous and memory matters; - you want per-field TTL on 7.4+. Choose a **JSON string** when: - the object is essentially always fetched and replaced whole (a cached API response, a rendered fragment); - the data is nested or list-shaped; - you want to reuse an existing serializer, schema and compression; - the value is a cache entry whose whole-object TTL and whole-object replacement are exactly the semantics you want. ## Practical middle grounds - **Hybrid**: hot, independently-mutated scalars as hash fields; a cold nested sub-tree serialised into one field. Explicit, and honest about which parts are opaque. - **Two keys**: a hash for mutable state and a string for an immutable blob, sharing a key prefix (and a hash tag in a cluster so they stay in one slot). - **A JSON module**: the RedisJSON module adds path-addressable JSON with server-side get/set on sub-paths, which recovers partial access for nested documents. It is a module, not core Redis — call that out explicitly, because assuming `JSON.SET` exists on a stock server is a common mistake. ## The answer that lands Name the concurrency consequence explicitly. Most candidates list "partial reads" and stop; the interviewer is usually listening for the recognition that JSON-in-a-string turns every field update into a read-modify-write, and that fixing it costs you `WATCH` or Lua — whereas a hash gets it for free.