Achieving Microsecond Latency with Amazon DynamoDB Accelerator (DAX) - In-Memory Cache Design
Learn about read acceleration for DynamoDB with DAX, cache strategies, and cluster design.
DAX Overview
DAX is an in-memory cache for DynamoDB that reduces read latency from milliseconds to microseconds. Unlike ElastiCache (Redis/Memcached), DAX provides a DynamoDB-compatible API, but connecting requires the DAX client, so changing the endpoint alone does not switch over. A DAX cluster is deployed within a VPC, with each node in the cluster holding a replica of the same cached data. The primary node handles writes while replica nodes distribute reads, and replicas are automatically promoted in case of primary failure.
Cache Strategy and Cluster Design
The item cache caches results from GetItem and BatchGetItem, with automatic expiration via TTL (default 5 minutes). The query cache caches result sets from Query and Scan operations. With write-through, the item cache is also updated when PutItem or UpdateItem is executed (the query cache is not updated). A minimum of 3 nodes (Multi-AZ) is recommended for the cluster, and node type should be selected based on the volume of data to cache. dax.r5.large suits medium workloads, while dax.r5.xlarge is appropriate for large hot datasets.
Cache Strategy and Consistency
DAX manages caching in two layers: item cache and query cache. The item cache holds GetItem and BatchGetItem results with a TTL (default 5 minutes). The query cache holds Query and Scan results. Write operations (PutItem, UpdateItem, DeleteItem) are reflected in both DAX and DynamoDB through write-through. Eventually consistent reads are served from the cache, while strongly consistent reads access DynamoDB directly. There is a trade-off where shorter TTL settings reduce cache hit rates, while longer settings decrease data freshness.
DAX vs. ElastiCache Comparison
DAX is a cache dedicated to DynamoDB, and you adopt it by replacing the application's SDK with the DAX client. DAX handles invalidation of the item cache, so there is no need to implement invalidation logic on the application side. ElastiCache (Redis), on the other hand, can cache data from sources other than DynamoDB (RDS, external API responses) and leverages data structures such as Pub/Sub and sorted sets. DAX's query cache determines hits by exact parameter match, so hit rates decrease for workloads where Query filter conditions change frequently. In such cases, another option is to design application-side cache keys with ElastiCache. TransactGetItems requests are passed through to DynamoDB and their results are not cached, so the benefit is limited for workloads dominated by transactional reads.
Design Pitfalls and Operational Considerations
DAX clusters must be deployed within a VPC. When connecting from Lambda, place Lambda in the same VPC. During DAX node failures, the client SDK automatically retries, but read latency increases during failover. Applications should be designed to tolerate this temporary latency increase. Item cache and query cache TTLs can be configured independently. For tables with frequent writes, shorten the item cache TTL and review the query cache TTL along with it to maintain data freshness. Nodes can be added and removed while the cluster is running, and a new node synchronizes cache data from the other nodes, so complete the change before expected traffic peaks.
DAX Pricing
DAX pricing is based on hourly charges per node. The rate varies by node type. A configuration of 3 or more nodes (Multi-AZ) is recommended, so charges apply for each of those nodes. Compare the cost savings from reducing DynamoDB Read Capacity Units (RCU) against DAX node costs to determine whether DAX adoption is advantageous for read-heavy workloads. The higher the cache hit rate, the more DynamoDB RCU you can reduce.
Summary
DAX is an in-memory cache for DynamoDB that achieves microsecond-level read latency. It maintains write consistency through write-through caching while reducing read load with two-layer caching of items and queries. The effect of reducing DynamoDB RCU costs is more likely to appear in read-intensive workloads with high cache hit rates.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon DynamoDB Accelerator official page
- Amazon DynamoDB official page
- Amazon VPC official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.