DynamoDB Accelerator (DAX)

Amazon DynamoDB Accelerator (DAX) is a fully managed, clustered, in-memory cache that sits between your application and DynamoDB. It delivers up to 10x performance improvement for read-intensive workloads by reducing response times from milliseconds to microseconds. DAX is designed specifically for DynamoDB — it caches the results of GetItem, BatchGetItem, Query, and Scan operations, as well as individual item caches for eventually consistent reads. It does NOT cache write operations (PutItem, UpdateItem, DeleteItem) directly; instead, it uses a write-through strategy: when you write to DynamoDB via DAX, the cache is updated synchronously.

DAX operates as a write-through cache with two primary caches: - Item cache: caches individual items retrieved by primary key (GetItem, BatchGetItem). - Query cache: caches the results of Query and Scan operations, including the full result set and the query parameters.

When an application sends a read request through a DAX endpoint, DAX first checks the item cache. If found (cache hit), it returns the item immediately. If not (cache miss), DAX sends the request to DynamoDB, stores the result in the cache, and returns it. For writes, DAX writes to DynamoDB first, then updates the cache synchronously (write-through). If the write fails, the cache is not updated.

DAX uses a cluster of nodes: a primary node and up to 9 read replicas (total 10 nodes). The primary handles writes and cache management; replicas can serve reads. DAX nodes communicate internally to maintain cache consistency. The cache uses a Least Recently Used (LRU) eviction policy when memory is full.

Creating a DAX cluster via AWS CLI:

aws dax create-cluster \
    --cluster-name my-dax-cluster \
    --node-type dax.r5.large \
    --replication-factor 3 \
    --iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \
    --subnet-group-name my-subnet-group \
    --security-group-ids sg-12345678

Verifying cluster status:

aws dax describe-clusters --cluster-name my-dax-cluster

Testing connectivity from an EC2 instance (DAX client SDK required):

import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.document.DynamoDB;
import com.amazonaws.services.dynamodbv2.document.Item;

AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard()
    .withEndpointConfiguration(
        new AwsClientBuilder.EndpointConfiguration("dax://my-dax-cluster.abcdef.clustercfg.dax.use1.cache.amazonaws.com:8111", "us-east-1"))
    .build();
DynamoDB dynamoDB = new DynamoDB(client);
Item item = dynamoDB.getTable("MyTable").getItem("pk", "value");

A mobile gaming company uses DynamoDB to store player scores and leaderboards. During peak hours, thousands of players query the top 100 scores every second. Without caching, each query triggers a Scan with a SortKey condition, causing high DynamoDB read capacity consumption and latency spikes. The company deploys a DAX cluster with three r5.large nodes (one primary, two replicas) in the same VPC as their game servers. They set the query cache TTL to 10 seconds, balancing freshness with performance. Result: read latency drops from 5 ms to under 100 µs, and DynamoDB read capacity usage decreases by 70%. Misconfiguration: initially, they set the TTL to 60 seconds, causing players to see stale scores for too long, leading to complaints. They reduced TTL to 10 seconds after monitoring cache hit rates and staleness.

An e-commerce platform stores product details (price, description, inventory count) in DynamoDB. The product catalog is read-heavy, with frequent updates to inventory during checkout. They use DAX with write-through to ensure that inventory changes are reflected immediately in the cache. However, they also have a separate reporting application that reads directly from DynamoDB, bypassing DAX. This causes cache inconsistency: after a direct update by the reporting app, DAX still serves stale data until TTL expiry. They solve this by either routing all writes through DAX or implementing a cache invalidation mechanism via DynamoDB Streams and Lambda to purge the relevant DAX cache entries. They chose the latter, using a Lambda function that listens to DynamoDB Streams and calls the DAX DeleteItem API to remove the stale item from the cache.

A financial firm uses DynamoDB to store real-time stock prices. The dashboard updates every second and requires strongly consistent reads to avoid showing stale prices. Initially, they tried using DAX for lower latency, but DAX only supports eventually consistent reads, so traders saw outdated prices during high volatility. They removed DAX and instead provisioned higher read capacity on DynamoDB, using DAX only for non-critical historical data queries. This teaches an important lesson: DAX is not suitable for workloads that demand strong consistency. The exam often tests this distinction.