A developer is creating a database of products. Queries for frequently accessed products must have retrieval times of microseconds. To ensure data consistency, the application cache must be updated wh

DynamoDB is a fully managed NoSQL database, and DAX is its purpose-built in-memory cache that provides microsecond read latency. DAX uses a write-through caching strategy by default, meaning every write to DynamoDB also updates the DAX cache, ensuring data consistency whenever products are added, changed, or deleted.

RDS with ElastiCache using lazy loading only populates the cache on a cache miss, meaning stale data can be served until the TTL expires or the cache is explicitly invalidated; it does not automatically ensure consistency on every write.

Lazy loading caching strategy means the cache is only updated after a cache miss (a read), so writes that add, change, or delete products will not immediately reflect in the cache, violating the consistency requirement.

DAX is a caching layer designed exclusively for DynamoDB and cannot be used in front of an RDS database; placing DAX in front of RDS is not a valid architecture.