Caching Systems
Distributed in-memory key-value store database designed to accelerate database reads, store user sessions, and compute pub/sub tasks.
1. System Requirements
- Provide sub-millisecond key-value reads and writes.
- Support cache expiration times (TTL) and eviction policies (LRU, LFU).
- Support rich data structures (Strings, Hashes, Lists, Sets, Sorted Sets).
- Extremely low latency profiles (< 1ms read).
- High availability using Redis Sentinel or Redis Cluster sharding.
2. Scale & Resource Estimates
Throughput: A single node can process over 100,000 Operations Per Second (OPS). Clusters scale linearly to millions of OPS.
Storage & RAM: Fully RAM-bound. 10 Million keys averaging 200 bytes = ~2 GB RAM requirement.
3. System API Endpoints
// Cache-Aside lookup
value = Redis.get("user:4412")
if (value == null) {
value = DB.query("SELECT * FROM users WHERE id=4412")
Redis.setex("user:4412", 3600, value)
}4. Database Schema Design
Redis Cache Key Layout:
Key: "session:token-xyz123"
Value: { "user_id": 4412, "roles": ["admin"] } (TTL: 86400)5. Interactive High-Level Architecture
6. Scalability Deep Dive & Bottlenecks
Caching reduces primary database load and query latency. In the Cache-Aside pattern, the application checks the cache first. On a cache miss, it queries the database, writes the result to the cache, and returns it. To prevent stale data, Cache Eviction policies like Least Recently Used (LRU) automatically purge older records when RAM capacity reaches thresholds.
7. Production Scaling Strategies
Redis Cluster: Sharding keys across up to 1000 nodes using hash slots to scale RAM and write throughput.
Cache Stampede Protection: Implementing distributed locks (mutexes) so only one server recalculates a cache miss at a time.
Read Replicas: Routing read requests to read-only replica nodes while writes are processed by the primary master node.
8. Runnable Production Starter Code
Scaffold