DynamoDB Accelerator (DAX)

It’s a caching layer technology specifically for DynamoDB, but unlike general purpose caches it’s tightly integrated with DynamoDB and transparent to the application#.

Usually, with caches, the application has a separate endpoint for the cache. When it needs data, it checks the cache and in case of cache miss, queries the database using its endpoint (and then writes the data to the cache, replicating it to the read replicas). With DAX you have a single DAX endpoint you send a query request to using the DAX SDK, that endpoint will always provide a response but two things can happen:

  • DAX has the result cached: it returns the result immediately, without connecting to the DB.

  • DAX does not have the result cached: it sends the query to the DB, returns the result and also stores it in its cache.

In case of Cache Hits, results are returned in microseconds. For Cache Misses results are returned in single-digit milliseconds.

Since not all the reads reach the DynamoDB table, you achieve significant cost reductions, in fact, you can afford to provision less RCUs.

The application only sees an endpoint that always responds.

DAX can use Write-Through, where data is written to the cache when a write operation is perfomed on the database.

It allows reducing the admin overhead.

You should NOT use DAX if Strong Consistency is required!.

Architecture

A DAX cluster is designed to be deployed into multiple AZs in a VPC, with a single elected primary node and multiple READ replicas. This provides high availability.

What the application gets is an endpoint that handles all.

Dax can scale UP or OUT: using bigger instances or more instances.

DAX Caches

DAX keeps two caches:

  • An Item Cache for the GetItem and BatchGetItem operations, in which you specify PK and, optionally, a SK.

  • A Query Cache for the Query and Scan operations, that also stores the parameter used for Queries and Scans. Basically the query/scan parameters become the cache key.