High Level Design
Redis & Memcached
Redis architecture, use cases, failure modes and mitigations, design FAQs, and a Memcached comparison — everything needed for a caching deep-dive.
Redis#
Redis is an in-memory, low-latency data store used primarily for caching, fast data access, coordination, and real-time workloads.
Why Redis?#
| Problem at Scale | How Redis Helps |
|---|---|
| Databases become latency bottlenecks | Offloads reads from databases |
| Repeated reads overwhelm storage | Reduces response latency from ms → μs |
| Stateless services need shared fast state | Enables fast, shared, ephemeral state |
Use Redis When#
- High read-to-write ratio
- Frequently accessed but rarely updated data
- Strict latency SLAs (< 10ms)
- Counters, sessions, rate limits, distributed locks
Avoid Redis When#
- Data must be permanently durable
- Large objects or heavy analytical queries needed
Architecture#
Client → Service → Redis
↓ (miss)
Database
↓
Redis (populate)
Redis sits between the application and database, absorbing read pressure.
Core Components#
| Component | Responsibility |
|---|---|
| Redis Server | Stores data in memory |
| Client Library | Handles serialization, retries |
| Eviction Policy | Manages memory pressure |
| Persistence (RDB/AOF) | Optional durability |
| Replicas | Read scaling and failover |
| Redis Cluster | Horizontal sharding |
Scalability#
- Vertical scaling limited by RAM
- Horizontal via Redis Cluster (hash-slot sharding)
- Reads scale using replicas
- Writes scale via key partitioning
Bottlenecks: Hot keys; single-threaded command execution.
Common Failure Scenarios#
| Problem | Impact | Mitigation |
|---|---|---|
| Cache stampede | DB overload on cache miss | Request coalescing — only one request recomputes, others wait |
| Hot keys | Single node meltdown | Key sharding — split logical hot key into multiple physical keys |
| TTL expiry burst | Latency spikes | Staggered TTLs + background refresh before expiry |
| Eviction misconfig | Critical data loss | Proper eviction policy (volatile-LRU) + DB fallback |
| Redis restart | Cold cache | Pre-warm critical keys immediately after traffic is routed |
Design FAQs#
Cache-aside vs write-through?
Cache-aside is the default. Application reads from Redis first; on miss, fetches from DB and populates Redis. Writes go directly to DB (Redis = optimization layer). If Redis fails, writes are unaffected. Consider write-through only when strong read consistency is required.
TTL vs manual invalidation?
Prefer TTL-based expiration — simpler and resilient to missed invalidation paths. TTL guarantees eventual correctness. For critical data, combine TTL with explicit invalidation on writes.
Strong consistency or eventual consistency?
Most Redis use cases operate with eventual consistency — acceptable for caches, feeds, session data. If strong consistency is required, restrict reads to the primary, but at the cost of latency and availability.
Single node vs Redis Cluster?
Single node for small-scale or non-critical workloads. Redis Cluster for high data size or throughput requirements — shards horizontally, adds replicas. Choice driven by data size, not just traffic.
Persistence required?
Default: treat Redis as disposable; rely on DB as source of truth. Enable persistence only when cache rebuild is expensive or temporary data loss is unacceptable.
Top eviction policies?
volatile-lru or allkeys-lru — evict least recently used items under memory pressure. Helps retain hot data.
Memcached#
Memcached is a distributed, in-memory key-value cache designed for extremely fast reads with simple data models and no persistence.
When to Use Memcached#
✅ High read-to-write ratio
✅ Frequently accessed but rarely updated data
✅ Simple key-value data models
✅ Strict latency SLAs (< 2ms)
When to Avoid Memcached#
❌ Persistence needed
❌ Complex data structures required
❌ Atomic operations or coordination needed
Critical Design Decisions#
- Cache-Aside Only — no write-through or write-behind support
- TTL Is Mandatory — no manual invalidation guarantees; TTL controls correctness
- No Replication — if a node dies, the cache is lost; app must handle misses gracefully
Redis vs Memcached#
| Aspect | Memcached | Redis |
|---|---|---|
| Data model | Simple key-value | Rich structures (lists, sets, hashes, sorted sets) |
| Persistence | None | Optional (RDB / AOF) |
| Replication | No | Yes |
| Latency | Slightly lower | Very low |
| Use case | Pure cache | Cache + coordination + pub/sub |
Persistence: RDB vs AOF#
| Aspect | RDB | AOF |
|---|---|---|
| Definition | Point-in-time snapshots | Log of all write operations |
| Data Loss Risk | High (between snapshots) | Low (seconds or less) |
| Disk Usage | Small | Large |
| Restart Speed | Fast | Slower |
| Durability | Medium | High |
Interview FAQ Table#
| # | Question | Answer |
|---|---|---|
| 1 | Why Redis over direct DB? | Redis reduces read latency and offloads DB traffic by serving hot data from memory. |
| 2 | Is Redis a database? | Best treated as a cache/fast store — not a primary DB. Rely on a durable DB for correctness. |
| 3 | What consistency does Redis provide? | Eventual consistency (replication lag). Strong consistency possible via primary-only reads, but at availability cost. |
| 4 | How to prevent cache stampede? | Request coalescing + TTL jitter + rate-limited DB fallback. |
| 5 | What if Redis goes down? | Cache misses spike; traffic falls back to DB. System must degrade gracefully. |
| 6 | How does Redis scale? | Vertically via RAM; horizontally via Redis Cluster (hash slots) + replicas. |
| 7 | What are hot keys? | Frequently accessed keys overloading a single node. Mitigate via key sharding or local in-process caching. |
| 8 | Can Redis do distributed locking? | Yes, but only for best-effort coordination — not strict correctness. Timeouts and failure handling are critical. |