Cache and In-Memory Databases
Last reviewed: August 2026
Overview
Section titled “Overview”Database lookups incur disk I/O, taking several to tens of milliseconds. An in-memory cache stores frequently accessed data in memory, cutting response time down to microseconds.
Cache patterns
Section titled “Cache patterns”| Pattern | Behavior | Suitable for |
|---|---|---|
| Cache-Aside | App checks the cache → on a miss, queries the DB → stores it in the cache | Read-heavy, most common |
| Write-Through | App writes to the cache → the cache synchronously writes to the DB | Consistency matters, write latency tolerable |
| Write-Behind | App writes to the cache → the cache asynchronously writes to the DB | Write performance matters, temporary inconsistency tolerable |
| Read-Through | The cache performs the DB lookup on the app’s behalf | When the cache library supports DB integration |
Comparison of vendor services
Section titled “Comparison of vendor services”| Vendor | Service | Engine | Characteristics |
|---|---|---|---|
| AWS | ElastiCache for Valkey | Valkey (Redis fork) | Default recommendation. Serverless option. Vector search support |
| AWS | ElastiCache for Redis | Redis | For compatibility with existing workloads |
| AWS | MemoryDB for Valkey | Valkey | Durability guaranteed (disk persistence). Usable as a primary DB |
| Azure | Azure Cache for Redis | Redis | Enterprise tier (based on Redis Enterprise) |
| Google Cloud | Memorystore for Valkey | Valkey | Default recommendation. Cluster mode, automatic failover |
| Google Cloud | Memorystore for Redis | Redis | For existing compatibility |
| OCI | OCI Cache | Redis-compatible | Managed Redis cluster |
Valkey/Redis vs. Memcached
Section titled “Valkey/Redis vs. Memcached”| Item | Valkey/Redis | Memcached |
|---|---|---|
| Data structures | String, Hash, List, Set, Sorted Set, Stream | String only (key-value) |
| Persistence | RDB/AOF snapshots possible | None (pure cache) |
| Replication/HA | Replicas + automatic failover | None (client-side sharding) |
| Pub/Sub | Supported | Not supported |
| Suitable for | Session store, leaderboards, real-time analytics, Pub/Sub | Simple caching, large-object caching |
What to choose when
Section titled “What to choose when”| Requirement | Recommendation |
|---|---|
| DB read load distribution (general cache) | ElastiCache/Memorystore Valkey (or Redis) (Cache-Aside) |
| Session store (TTL + structured data) | Valkey / Redis (Hash type) |
| Primary DB replacement (durability required) | MemoryDB for Valkey |
| Simple key-value, maximum throughput | Memcached |
| Real-time leaderboard/counters | Valkey / Redis (Sorted Set) |
Common mistakes
Section titled “Common mistakes”- Using the cache as permanent storage — A cache can disappear at any time. If original data isn’t stored elsewhere, an outage causes data loss.
- Not setting a TTL on every key — Caching without TTLs leaves data around forever, causing inconsistency with the DB and eventual memory exhaustion.
- Not implementing a fallback for cache failure — In a cache-dependent architecture, if the cache goes down the entire service can stop. Always secure a direct-to-DB path for cache misses.
Checklist
Section titled “Checklist”- Does every cache key have a TTL set that matches business requirements?
- Is a fallback path to query the DB directly implemented for cache failures?
- Have you checked cache memory usage monitoring and the eviction policy (LRU/LFU)?
References
Section titled “References”Open source
Section titled “Open source”- Valkey official site — a Redis fork under the Linux Foundation
- Valkey GitHub