Distributed Caching with Redis
Distributed Caching with Redis
While a local, in-memory cache is fast, it has a major limitation: each server has its own isolated cache. If you have 10 servers, you have 10 different caches. A Distributed Cache is a separate, dedicated cluster of servers that stores data in RAM and is accessible by all your application servers.
Redis is the industry standard for distributed caching.
Why Redis?
- High Performance: Sub-millisecond latency for most operations.
- Rich Data Structures: Unlike simple key-value stores, Redis supports Strings, Lists, Sets, Hashes, and even Geospatial indexes.
- Persistence: Can optionally save data to disk, allowing it to survive a restart.
- Replication and High Availability: Supports primary-replica setups and automatic failover via Redis Sentinel.
- Atomic Operations: Many complex operations (like incrementing a counter or adding to a list) are atomic, preventing race conditions.
Scaling Redis
As your cache needs grow, you can scale Redis in two ways:
- Replication (Read Scaling): Add replicas to your primary node. Applications can read from any replica but must write only to the primary.
- Sharding (Write Scaling / Redis Cluster): Split your data across multiple Redis nodes. Each node handles a subset of the keyspace. This allows for virtually unlimited capacity and throughput.
A Common Redis Use Case: Session Management
- 1Step 1
A user logs in successfully. Your application generates a unique session ID (e.g., a UUID).
- 2Step 2
Save the user's session data in Redis using a Hash or String. Set a TTL corresponding to your session timeout.
1SET session:abcd-1234 '{"user_id": 99, "role": "admin"}' EX 3600 - 3Step 3
Send the session ID back to the user's browser in a secure, HTTP-only cookie.
- 4Step 4
For every incoming request, the app reads the cookie, fetches the session data from Redis, and verifies the user. Because Redis is distributed, this works no matter which app server handles the request.
- 5Step 5
On logout, simply delete the key from Redis. If the user is idle, Redis will automatically evict the session after 1 hour (the TTL we set).
Redis vs. Memcached
| Feature | Redis | Memcached |
|---|---|---|
| Data Types | Rich (Lists, Sets, etc.) | Strings only |
| Persistence | Yes (RDB/AOF) | No |
| Replication | Yes | No (Client-side sharding only) |
| Architecture | Single-threaded (mostly) | Multi-threaded |
| Best For | Complex objects, persistence needed | Simple key-value caching |
Common Mistakes
- Using Redis as a Primary Database: While Redis has persistence, it is not designed to replace a durable relational database. Use it for data that can be lost without a catastrophe.
- Keyspace Pollution: Not using namespaces or prefixes for your keys (e.g.,
user:123instead of just123), leading to collisions between different parts of your app. - Big Keys: Storing massive multi-megabyte JSON blobs in a single Redis key. This can block the single-threaded Redis engine and cause latency spikes.
Recap
- Redis is a powerful, distributed, in-memory data store.
- It provides a shared state for multiple application servers.
- Sentinel handles high availability; Cluster handles massive scaling.
- Use Hashes and Sets to optimize memory usage compared to raw strings.
Knowledge Check
Why is a distributed cache like Redis better than a local in-memory cache for a horizontally scaled application?