Why Redis is Fast
Redis stores all data in RAM (memory) instead of on disk. RAM access is ~100,000× faster than disk access. A Redis GET operation typically completes in under 1 millisecond — far faster than any database query. This speed makes it ideal as a cache layer in front of slower data stores.
Redis Data Structures
| Type | Use Case | Key Commands |
|---|---|---|
| String | Caching, counters, flags, tokens | SET, GET, INCR, DECR, EXPIRE |
| Hash | User profiles, session data, config | HSET, HGET, HGETALL, HDEL |
| List | Queues, activity feeds, recent items | LPUSH, RPUSH, LPOP, LRANGE |
| Set | Tags, unique visitors, friend lists | SADD, SMEMBERS, SISMEMBER, SUNION |
| Sorted Set | Leaderboards, priority queues, time-series | ZADD, ZRANGE, ZRANK, ZSCORE |
| HyperLogLog | Approximate unique count (e.g. daily active users) | PFADD, PFCOUNT |
| Stream | Event log, durable pub/sub, message queue | XADD, XREAD, XRANGE |
Common Redis Use Cases
1. Database Query Caching
2. Rate Limiting
3. Leaderboard (Sorted Set)
Redis vs Memcached
| Feature | Redis | Memcached |
|---|---|---|
| Data types | Strings, hashes, lists, sets, sorted sets, streams | Strings only |
| Persistence | RDB + AOF | None |
| Replication | Built-in master-replica | None built-in |
| Clustering | Redis Cluster (built-in) | Client-side sharding only |
| Pub/Sub | Yes | No |
| Threading | Single-threaded (I/O multiplexing) | Multi-threaded |
| Memory efficiency | Slightly lower | Slightly higher for simple strings |
Redis Persistence Options
- No persistence: Pure cache — data lost on restart. Fastest option.
- RDB snapshots: Save dataset to disk every N seconds. Fast restarts, may lose recent writes.
- AOF (Append-Only File): Log every write command. More durable — can lose at most 1 second of data (fsync every second). Larger files.
- RDB + AOF: Best durability — use AOF for recovery, RDB for fast startup.
💡 Use Redis Cloud or Managed Redis
AWS ElastiCache (Redis), Azure Cache for Redis, and Redis Cloud are managed services that handle replication, failover, patching, and backups automatically. For most teams, the operational overhead of self-hosted Redis is not worth it unless you have specific requirements.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — Redis
Redis (Remote Dictionary Server) is an open-source, in-memory data store that operates as a database, cache, message broker, and queue. It stores data in RAM, making reads/writes microsecond-fast. Primary use cases: (1) Caching — cache database query results, API responses, computed values. (2) Session storage — store user sessions with automatic expiry. (3) Rate limiting — track request counts per user/IP. (4) Pub/Sub messaging — broadcast events to multiple subscribers. (5) Leaderboards — sorted sets for real-time rankings.
Both are in-memory caches, but Redis is far more capable. Memcached: simple key-value store, only strings, no persistence, no replication, multi-threaded. Redis: rich data structures (strings, lists, sets, sorted sets, hashes, streams), optional persistence to disk, built-in replication and clustering, single-threaded (but extremely fast), pub/sub, Lua scripting. Choose Memcached only if you need simple caching at very high scale and want multi-threading. For everything else, Redis is the better choice.
Redis has two persistence options: RDB (snapshot) — periodically saves a point-in-time snapshot to disk. Fast restore but may lose recent writes. AOF (Append-Only File) — logs every write command; on restart, replays the log. More durable but larger files. You can use both together for maximum durability (AOF for durability, RDB for fast restarts). Or disable persistence entirely for a pure cache where losing data on restart is acceptable.
Redis supports multiple data types: String (text, numbers, binary), List (ordered collection, push/pop from head/tail), Hash (field-value pairs — like a dictionary), Set (unique unordered values), Sorted Set (unique values with scores — perfect for leaderboards), HyperLogLog (approximate unique count), Stream (append-only log), Bitmap (bit arrays). These built-in structures mean you can implement complex patterns (leaderboards, rate limiters, activity feeds) without application-level code.
Every Redis key can have a TTL (Time to Live) set in seconds or milliseconds. Redis uses two mechanisms: passive expiry (key is checked and deleted when accessed and found expired) and active expiry (Redis periodically scans a sample of keys with TTLs and deletes expired ones). You set expiry with EXPIRE key seconds or SET key value EX seconds. This makes Redis ideal for caches and sessions — data automatically disappears after a set time with no cleanup code needed.
Redis Pub/Sub (publish/subscribe) is a messaging pattern where publishers send messages to channels and subscribers receive them. Publishers do not know who receives the message; subscribers do not know who sent it. This decouples producers from consumers. Use cases: real-time notifications, live dashboards, chat systems, event broadcasting. Important caveat: Redis Pub/Sub does not persist messages — if a subscriber is offline when a message is published, it misses it. For durable messaging, use Redis Streams instead.