Most Redis users only use strings and lists. The other data structures (sorted sets, hashes, streams, HyperLogLog, bitmap) are what make Redis genuinely powerful beyond 'cache.' Each one solves a specific class of problem better than any other system.
Sorted sets (ZSET)
Members have an associated score; you can query by rank or score range in O(log N). Use cases: leaderboards (score = points, member = user_id), time-series indexing (score = timestamp), priority queues (score = priority). One ZSET, multiple query patterns.
Streams (XADD / XREAD)
Append-only log with consumer groups, like a tiny Kafka. Each entry has an ID (auto-generated timestamp + sequence). Consumers track their position. Use for: event sourcing in small apps, work queues that need replay, real-time notifications. ~1M msg/sec on a single Redis node.
HyperLogLog (PFADD)
Probabilistic cardinality estimator. Counts unique items with 0.81% error using ~12 KB regardless of input size. Use for: unique-visitor counts, distinct-event counts, anything where you don't need the exact items, just the count.
Bitmaps (SETBIT)
Each key is a bit array indexed by integer offset. 1B bits = 128 MB. Use for: per-day login tracking (bit set per user_id per day), feature flag rollouts (bit per user), Bloom-filter-style membership tests at scale.
Geo (GEOADD / GEORADIUS)
Add (lat, lon, name) tuples to a key, query by radius. Backed by sorted set with geohash scores — leverages the sorted-set internals for spatial indexing. Use for: 'find drivers near me,' 'stores within 5 km.' Doesn't replace PostGIS, but for simple distance queries it's perfect.