Redis Data Structure Chooser

Use String for simple key-value storage where the entire value is fetched/written atomically — like a serialized session JSON. Use Hash when you need to read or update individual fields without fetching the entire object: HGET session:123 userId is more efficient than GET+deserialize+re-serialize when you only need one field. For sessions with 3-5 fields, Hash is typically more memory-efficient and enables partial updates. For complex nested structures, JSON with RedisJSON module or a serialized String is simpler.

A Sorted Set stores unique members, each with an associated floating-point score, and maintains members sorted by score at all times. Operations are O(log N). Common use cases: leaderboards (score = points, rank by ZREVRANK), rate limiting (score = timestamp, ZRANGEBYSCORE to count events in a time window), job priority queues (score = priority), activity feeds (score = Unix timestamp for chronological ordering), and autocomplete (store prefix strings with a score and ZRANGEBYLEX for prefix queries).

Use a Sorted Set per user. Key = rate_limit:user:{id}. On each request: ZADD key currentTimestamp uniqueRequestId (NX), ZREMRANGEBYSCORE key 0 (currentTime - windowMs) to evict old entries, ZCARD key to count requests in the window, expire the key with EXPIRE. If count > limit, reject the request. This sliding window approach is more accurate than a fixed window counter. For very high throughput, the fixed window approach (INCR + EXPIRE) is simpler and faster at the cost of accuracy at window boundaries.

Pub/Sub is for fire-and-forget messaging where offline subscribers miss messages — use for live chat, real-time notifications, or broadcasting to connected clients. Redis Streams (XADD/XREAD) are like a persistent log with consumer groups — subscribers that disconnect can resume from where they left off using the last message ID. Use Streams for event sourcing, reliable task queues, audit logs, or any case where you cannot afford to miss messages. Streams support multiple consumer groups and acknowledgment (XACK), making them suitable for producer-consumer patterns.

EXPIRE sets a timeout in seconds from the current time: EXPIRE key 3600 expires in 1 hour. EXPIREAT sets an absolute Unix timestamp for expiration: EXPIREAT key 1735689600. PEXPIRE and PEXPIREAT work the same way but in milliseconds. Use EXPIREAT when you need to expire a key at a specific wall-clock time (e.g., end of business day). Use EXPIRE for relative TTLs. PERSIST removes an existing TTL. TTL key returns remaining seconds (-1 = no TTL, -2 = key doesn't exist).

Use colon-separated namespaces: type:entity:id:field — for example session:user:12345, cache:product:slug:iphone-15, rate_limit:api:user:99. Always document your key schema. Avoid key patterns that make KEYS * dangerous (it blocks Redis) — use SCAN with cursor instead for key enumeration. Set appropriate TTLs on all keys to prevent unbounded memory growth. Group related keys with consistent prefixes to enable targeted flushing with SCAN + DEL patterns. Use short but descriptive names — Redis key size affects memory; avoid excessively long keys.