Redis
Redis (Remote Dictionary Server) is an in-memory data-structure store. By keeping data in RAM, it serves reads and writes in microseconds, and it offers far more than plain key-value: strings, hashes, lists, sets, sorted sets, and streams, each with purpose-built commands.
Most often Redis sits beside your primary database as a cache or for ephemeral data — sessions, rate-limit counters, queues, leaderboards — where speed matters and the data is short-lived or reconstructable.
TL;DR
- An in-memory store with microsecond latency and rich data structures.
- Great for caching, sessions, rate limiting, queues, and leaderboards.
- Set TTLs and an eviction policy — Redis can't exceed available RAM.
- Single-threaded for commands, yet extremely fast via I/O multiplexing.
- Configure persistence (RDB/AOF) if you need durability.
Quick Example
The canonical cache pattern — store a value with a time-to-live so it expires automatically:
Core Concepts
- Data structures — strings, hashes, lists, sets, sorted sets (great for leaderboards), and streams (append-only logs).
- TTL / expiration — keys can auto-expire; essential for cache hygiene.
- Persistence — RDB (point-in-time snapshots) and AOF (append-only log) trade durability against performance.
- Single-threaded commands — no locking complexity; throughput comes from non-blocking I/O.
- Pub/Sub & streams — message broadcasting and durable event logs.
Common Uses
- Caching — store hot query/computation results in front of a slower database.
- Sessions — fast, shared session store across app instances.
- Rate limiting — atomic counters with TTL (see Rate Limiting).
- Queues & pub/sub — background jobs and real-time messaging.
Best Practices
- Always set TTLs on cache keys and choose an eviction policy (e.g.
allkeys-lru). - Keep values small; avoid giant keys and huge collections that block the server.
- Use pipelining to batch commands and cut round trips.
- Treat Redis as a complement to your durable database unless you've deliberately configured persistence for primary use.
Comparison: Redis vs Memcached
Common Mistakes
Caching without a TTL
Treating Redis as a durable database by default
FAQ
Is Redis a cache or a database?
Both, but most often a cache or store for ephemeral data. It can be a primary database with persistence (RDB/AOF) enabled, but it's typically paired with a durable store like PostgreSQL, holding hot or short-lived data.
How does persistence work?
RDB takes periodic point-in-time snapshots (compact, fast restore, but you can lose recent writes). AOF logs every write for better durability at some performance cost. You can use either, both, or neither depending on how much data loss you can tolerate.
Why is a single-threaded store so fast?
Redis avoids lock contention and context-switching by handling commands on one thread, using non-blocking I/O multiplexing to juggle many connections. Since operations are in-memory and O(1)/O(log n), the thread is rarely the bottleneck.
Redis or Memcached?
Memcached for a dead-simple string cache. Redis for everything else — richer data structures, optional persistence, pub/sub, TTLs, and atomic operations make it the more versatile default.
Related Topics
- Caching — Patterns Redis implements
- Rate Limiting — Counters in Redis
- PostgreSQL — The durable store Redis fronts
- Message Queues — Redis as a broker
- Databases — Choosing a data store