DAX Caching Interview Questions

DAX is a DynamoDB-specific write-through cache cluster in your VPC. It shines on GetItem, BatchGetItem, Query, and Scan by serving microsecond reads from memory when the item is warm. It is not a general Redis replacement for pub/sub or arbitrary data structures.

Writes go through DAX to DynamoDB and update the cache, so the writing client’s subsequent Get can hit fresh data. Other clients still see DAX’s eventual consistency window. Writes are not faster than DynamoDB; DAX is a read optimizer.

Cached reads are eventually consistent. ConsistentRead=true typically bypasses the cache and hits DynamoDB. If a path must always see the latest write, it should not use DAX or must bypass it explicitly.

It can cache Query/Scan result sets, but large or frequently changing queries churn the cache and help less than point lookups. Hot GetItem keys are the textbook win. If your pain is Scan volume, fix the model before buying DAX nodes.

Use the DAX SDK/client with the cluster endpoint inside the VPC, not the public DynamoDB endpoint, for cached calls. Security groups and IAM still apply. Pointing the AWS DynamoDB SDK at DAX without the DAX client is a common setup miss.

Fail open to DynamoDB or fail closed based on product needs—but decide explicitly. A hard dependency with no fallback turns a cache outage into a full outage. Timeouts must be shorter than user-facing SLOs so you can fall back.

A hot key still concentrates writes on one DynamoDB partition; DAX only hides repeated reads of that item. Write throttling and item-collection size remain. Caching a bad model delays the incident until a write storm or cache miss storm.

After a write that another client must see immediately, or on financial/read-your-writes paths. Bypassing too often wastes DAX. Document which APIs are cache-OK versus DynamoDB-direct so new endpoints do not guess.

DAX is memory-bound; large items and wide Query pages evict useful keys. Keep cached items small and avoid stuffing 300 KB documents if you wanted a hot-key cache. Watch item-count and memory metrics, not only request counts.

A Put straight to DynamoDB can leave DAX serving a stale image until TTL or eviction. All writers in the region should use the DAX write path if readers use DAX. Split-brain clients are the usual source of “I updated it but the app shows old data.”

A primary node handles writes; replicas serve reads in other AZs. Replica failure should not require application changes if the client uses the configuration endpoint. Node type and replica count are availability and hit-rate choices, not DynamoDB key design.

GetItem caches are precise; Query caches are sensitive to Limit, filters, and ExclusiveStartKey, so slightly different queries miss. Prefer GetItem for entities and keep Query shapes stable. Pagination keys mean page 2 is a different cache entry than page 1.

DAX lives in a VPC; lock security groups to app subnets, use IAM for cluster operations, and encrypt in transit as configured. Exposing the cluster beyond the app tier is a data exfiltration path. DynamoDB VPC endpoints alone do not replace DAX network design.

Hit ratio, cache memory, throttled requests on DAX, and DynamoDB throttles behind it. A low hit ratio with high Query diversity means you paid for a cluster that still hits DynamoDB. Rising DAX CPU with tiny items can mean too many connections or node undersizing.

Ship DAX behind a flag for read-heavy GETs, measure hit ratio and write throttles, and keep a ticket to shard or cache at the application layer if writes remain skewed. Treat DAX as a mitigator with an expiry date on the root-cause work. Never let it become the only “fix” in the design doc.

Writers in a batch job using the DynamoDB API leave DAX serving old profiles to the web fleet. Cross-region global tables plus DAX in one region add another lag layer. Define a single write entrypoint through DAX or bypass DAX for those item types.

Estimate hot item count × average item size with overhead, then pick nodes that hold that working set with headroom. CPU and network matter for high QPS small items. Scaling out replicas helps read QPS; it does not grow cache if every node holds a poor eviction pattern of huge items.

TransactGetItems and TransactWriteItems are not cached like simple Get/Put; transactional paths typically go to DynamoDB. Mixing cached GetItem with a later transaction on the same item can surprise you with staleness. Keep money paths off DAX.

Canary a percentage of reads through the DAX client, compare error rates and p99, and keep the DynamoDB endpoint as instant fallback. Cluster replacement and parameter-group changes need the same kill switch. A big-bang cutover on Black Friday is how cache becomes the outage.

When you need TTL policies DAX does not fit, computed responses, pub/sub, multi-store aggregation, or caching things that are not DynamoDB items. DAX wins when the working set is DynamoDB GetItem/Query and you want write-through with little app logic. Pick based on the object you cache, not the brand.