Database caching, invalidation, and source-of-truth boundaries

Identify the authoritative store and divide reads by staleness tolerance. Product descriptions may tolerate minutes; stock reservations and revocations may require current reads. Define cache key, tenant and authorization dimensions, TTL, expected update rate, and the exact invalidation trigger. If these facts are unknown, a cache can make a fast wrong answer. Measure baseline query latency, repeated-read ratio, and database load so the cache has a testable purpose.

Cache-aside loads the database on a miss and writes the result to cache. It is simple but permits stale values and stampedes unless writes invalidate and misses are coalesced or rate-limited. Write-through updates cache on the write path but adds latency and failure coordination. TTL limits age; it does not guarantee freshness immediately after a write. Versioned keys or event-driven invalidation can narrow stale windows, but failure handling must be specified.

CloudFront or API caching belongs near HTTP when whole responses are safely cacheable. ElastiCache is a general in-memory cache or data store for application objects, sessions, counters, and non-DynamoDB sources. DAX is DynamoDB-compatible acceleration for repeated eventually consistent reads where its integration and latency fit. DAX is not for strongly consistent reads and does not repair write-hot keys. RDS Proxy is not a cache: it pools relational connections. Read replicas execute database queries on replicated data; they are not key-value object caches.

Choose key granularity to avoid cross-tenant leaks and hot keys. Size memory for working set plus overhead, choose eviction behavior, and monitor hit ratio, latency, evictions, connection count, and source load. Multi-node deployment can improve cache availability, but asynchronous cache copies and eviction reinforce why durable truth remains elsewhere.

On cache outage, bounded fallback may query the source, but unlimited fallback can collapse the database. Use request coalescing, concurrency limits, and degraded responses where business rules permit. On source outage, serve stale content only for explicitly safe classes. Writes should either invalidate after authoritative commit or use a design that explains ordering; invalidating before a failed database write can cause needless misses, while failing to invalidate after success serves stale data.

Security includes encryption, network controls, authentication where supported, and keys that include authorization context. Cost includes nodes or serverless cache capacity and engineering complexity against saved database work. A low hit ratio or high write rate can make caching negative value. Validate with a write/read race, node restart, cold cache, and source slowdown. Caching is a performance integration, not durability, write scaling, connection management, or a universal rescue for poor queries.

Treat cache correctness as a state machine with four observable events: authoritative write starts, commit succeeds, invalidation is published, and the next reader misses or receives the new version. Test reordered and duplicated invalidations, not just the happy path. A version number in the cache key or value lets the application reject an older object after a race, while request coalescing prevents thousands of misses from becoming thousands of database queries. Security requires that a cache key include tenant and authorization-relevant dimensions whenever representation differs; encryption cannot repair a shared key that leaks another tenant's object. Compare memory capacity, replicas, network transfer, and invalidation engineering with the database CPU actually removed. If campaign reads are mostly unique, the low hit ratio makes ElastiCache a loser and query or index work becomes the likely next step.