Redis (Remote Dictionary Server) is one of the most versatile data stores in the stack — it is genuinely useful for multiple distinct purposes. The risk is using it for everything, which leads to confusion and misapplication. Here is where it excels and where it doesn’t.
What Redis Is (and Isn’t)
Redis is an in-memory data structure store: all data is held in RAM (with optional persistence to disk). This makes it extremely fast (sub-millisecond operations) but limited by available memory. It supports data structures that most databases don’t: strings, hashes, lists (ordered, with O(1) push/pop), sets (unordered, with O(1) membership test), sorted sets (with scores, efficient range queries), and bitmaps/HyperLogLog. It is not a replacement for a relational database — it lacks joins, complex queries, and ACID transactions at the database level (it has transactions at the single-operation level). Data that doesn’t fit in memory is a problem; data that needs complex querying is a problem.
What Redis Is For: The Canonical Use Cases
Caching: the most common use case. Store the result of expensive database queries, API calls, or rendered content with a TTL (time-to-live). `SET key value EX 300` stores a value for 300 seconds. Cache invalidation strategy (the hardest problem in caching): either time-based expiry (simple, may serve stale data), event-based invalidation (delete cache key when the underlying data changes — more complex but stays current), or cache-aside (application checks cache, on miss queries DB and writes to cache). Session storage: store user session data in Redis with a TTL matching the session timeout — fast, shared across application instances, automatically expires. Rate limiting: use Redis’s atomic increment (INCR) with an expiry to count requests per user per time window. `INCR ratelimit:user:123`, then check if the count exceeds the limit — works atomically and correctly even under concurrent load. Pub/Sub: Redis’s publish/subscribe system allows real-time messaging between application components — basic use case for notification systems and real-time features, though for serious message queuing, a dedicated queue (RabbitMQ, Kafka) is more appropriate. Leaderboards: sorted sets (ZADD, ZRANGE, ZRANK) make leaderboard implementation trivial — add a score, retrieve top-N, get rank — all O(log N) operations.
Data Persistence: The Common Misconception
Redis can persist data to disk (RDB snapshots or AOF append-only file), but it is not designed to be your primary data store for critical data. RDB snapshots: periodic snapshots of the dataset — some data loss possible between snapshots if Redis crashes. AOF: logs every write operation — much more durable but larger and slower. The correct model: Redis is a cache or secondary store; your PostgreSQL (or other relational/document DB) is the source of truth. If Redis data is lost or corrupted, you should be able to rebuild it from the primary store. Using Redis as a primary database for anything where losing the data is unacceptable is a misuse of the tool.
