The 30 second answer
Redis is also useful for shared counters and rate limits, sessions, leaderboards, expiring coordination state and messaging. I choose the data structure from the operation: a sorted set for rank, a counter with an atomic expiry policy for limits, and a stream with acknowledgment for recoverable work. The important question is what happens on disconnect, eviction or failover, because fast access alone does not guarantee durable business correctness.
A cache stores a reconstructible copy. Some Redis uses instead hold authoritative or coordination state, so losing a key can change the business result. Existing cache-aside and rate-limiter answers cover those individual patterns; this question is about selecting among non-cache uses and their different failure semantics.
Counters and rate limits. INCR is atomic for one counter. A window also needs expiry, and separate INCR/EXPIRE commands can leave a permanent counter if the client crashes between them. Use an atomic script or an appropriate transaction that implements the intended window semantics. Example: a fixed-window per-user key increments on each admitted attempt and expires at a defined boundary. Define whether a Redis outage rejects traffic or allows a limited degraded mode; an authentication-attempt limiter must not silently fail open. Atomic arithmetic does not make an entire multi-key business operation atomic.
Sessions and ephemeral workflow state. Shared session data allows requests to reach different stateless application instances. Give sessions an expiry and revoke/delete them on logout; eviction or a persistence gap may log users out or lose revocation state. Choose memory policy, access controls and durability according to that consequence. Do not put payment ledger truth in an evictable session cache. Distributed locks are a separate correctness problem: a lease expiring while a paused holder resumes requires stale-holder protection at the resource, not merely another SET command.
Leaderboards, priority and schedules. Sorted sets order members by score and provide rank/range operations. ZINCRBY updates an individual member's score; ZRANGE with score/rank options reads leaders. For a scheduled task queue, use execution time as score and atomically claim due tasks; merely reading due members lets two workers execute the same job. Define tie ordering and whether score updates must be idempotent when events redeliver. A leaderboard can often rebuild from a durable event log, which is a different recovery contract from an unreconstructible ledger.
Broadcast versus recoverable work. Pub/Sub is live fan-out with at-most-once delivery: a disconnected or failing subscriber can permanently miss a message. It is appropriate for disposable UI refresh hints if clients can fetch a fresh snapshot. It is not a durable job queue. Streams retain entries; consumer groups track delivery and pending acknowledgments. A worker processes an entry then acknowledges it. Recovery/reclaim can redeliver unfinished work, so effects still need idempotency. Configure retention and pending-entry recovery deliberately; trimming entries too early can destroy the data a slow/recovering consumer needs.
Broadcast hint: PUBLISH catalog-changed <id>
disconnected subscriber -> refetch snapshot on reconnect
Recoverable work: XADD work * taskId <id> action <operation>
XREADGROUP ... -> perform idempotent effect -> XACK ...
crashed worker -> inspect/reclaim pending entries -> retryThese are illustrative command flows, not a claim of exactly-once execution. Store a task/event identity with the effect when duplicates would be harmful. Monitor pending age and retry counts, not just stream length.
Durability and scaling. Redis persistence options trade performance and potential loss: snapshots are periodic, while AOF fsync policy affects the loss window. Replication/failover does not automatically turn each acknowledgment into a durable globally consistent commit. Make rebuild procedures explicit; use a durable database or log as the source for irreversible business state when the chosen Redis configuration cannot meet its requirements. Plan hot-key load, memory, key cardinality, expiry and bounded stream retention before choosing Redis because an example looked short.
Diagnostic differences. Missing live notifications point first to Pub/Sub subscriber connectivity and snapshot recovery. Growing stream pending age points to dead/slow consumers or failed acknowledgments, requiring recovery and idempotent retry. A rate limit never resetting suggests expiry/update atomicity or wrong key boundaries. A lost session after restart points to eviction/persistence policy. These require different actions; increasing a cache hit rate fixes none of them.