Core Data Types Practice

Use a hash for the session token so the TTL can live on one field, a list for online users, and Pub/Sub channels for the audit log.

Use a sorted set for everything that is ordered or unique — online users, leaderboard, delayed jobs, and the audit log keyed by timestamp, with scores doubling as deduplication keys for repeated events.

Use a JSON string for the profile fields, and a list for both delayed jobs and the audit log, popping entries as they replay.

Use string for the session token, hash for profile fields, set for online users, sorted set for leaderboard or delayed jobs, and stream for replayable audit logs.

Hashes are always cheaper because field lookups are O(1) while top-level key lookups must scan the keyspace.

Hashes only save memory once the combined fields exceed about a megabyte; below that, both layouts cost the same.

A hash reduces overhead when many fields belong to one entity; separate keys can still help independent TTLs, routing, or access patterns.

Separate keys are never useful once a hash exists, since per-field TTLs can be emulated with a second hash of deadlines at no cost beyond a little extra memory for the bookkeeping.

Uniqueness prevents hash collisions in the underlying table, while ordering falls out of insertion order.

A sorted set needs unique members so updates replace the right item and scores so the structure can answer ordered or ranked queries.

Scores already guarantee uniqueness, so member uniqueness is redundant and kept only for API compatibility, a holdover from when sorted sets were built on plain sets.

Ordering exists so members can be retrieved alphabetically, and the score is an optional display value.

Lists model simple queues, streams model durable replay with acknowledgements, and Pub/Sub models live delivery only.

Pub/Sub fits best, because messages queue per subscriber while it is disconnected; lists and streams require polling.

Lists and streams are equivalent for workers, with streams adding only an alternative syntax for popping entries.

Streams push to every consumer the way Pub/Sub does, so consumer groups exist mainly to slow producers down.

Use Pub/Sub with a persistence flag enabled, since channels can be configured to retain history for late subscribers for a configurable retention period per channel.

Use a list with RPOPLPUSH so every replay moves entries onto a backup list, preserving them for the next reader.

Use a stream for a replayable audit log because entries persist by ID; Pub/Sub would drop messages for disconnected consumers.

Use a sorted set scored by timestamp, which replays like a stream and also deduplicates identical events automatically.