SysPad › Lessons › database lessons › DynamoDB Accelerator (DAX)

How DynamoDB Accelerator (DAX) works

Write-through in-memory cache in front of DynamoDB. Microsecond-latency reads for cache hits; misses pass through to the table. Cluster is 1 primary + read replicas for HA.

DynamoDB is already single-digit-millisecond fast, so why cache it? Because some read-heavy apps want microseconds, and because hammering the same hot keys can cost real money in read capacity. DAX is a DynamoDB-aware cache that sits in front of your table, speaks the same API, and turns repeat reads into in-memory hits.

What you will learn

Why cache a database that’s already "fast"?
How does DAX slot in with almost no code change?
Which reads does DAX accelerate, and which quietly bypass it?
When is DAX worth it, and when is it just extra cost?

Why cache something already fast?

DynamoDB returns in a few milliseconds, but a read-heavy app reading the same items over and over can do better, and cheaper. DAX (DynamoDB Accelerator) keeps hot items in memory and serves them in microseconds, roughly a 10x latency improvement on hits.

A hit is also served by DAX, not DynamoDB, so it doesn’t consume table read capacity, which can dramatically cut cost on repetitive, read-heavy traffic.

⚓ Ideal for read-heavy or bursty apps, and hot-key reads like a trending product or a popular profile.

Almost a drop-in

DAX is API-compatible with DynamoDB. You point the DAX client at the DAX cluster instead of the table, and your existing read/write calls work, no rewriting your data access.

It’s write-through: writes go through DAX to DynamoDB and the cache is updated on the way, so cached items don’t silently go stale on your own writes.

What are the "item cache" and "query cache"?

DAX keeps two caches: the item cache for GetItem/BatchGetItem results (by key), and the query cache for Query/Scan results (by the request parameters). Each has its own TTL controlling how long entries stay before DAX refreshes them from DynamoDB.

What DAX accelerates (and what it doesn’t)

DAX serves eventually-consistent reads from its cache. That’s the catch worth memorising: a strongly-consistent read can’t be served from the cache, it passes straight through to DynamoDB and gets no DAX speedup.

When DAX earns its keep

DAX adds cluster cost and a small consistency caveat, so it’s not a default. It pays off when reads vastly outnumber writes, when the same items are read repeatedly, or when you need microsecond latency that DynamoDB alone won’t hit.

Flashcards

DynamoDB is already milliseconds-fast. What does DAX add?: Microsecond reads on cache hits (~10x faster), and hits don’t consume table read capacity, cutting cost on repetitive reads.
How much code changes to put DAX in front of DynamoDB?: Very little, DAX is API-compatible. Point the DAX client at the cluster; existing calls work. Writes are write-through (cache updated on write).
You issue a strongly-consistent read through DAX. Does the cache serve it?: No. DAX serves only eventually-consistent reads; strongly-consistent reads pass through to DynamoDB and get no speedup.
What two caches does DAX maintain?: An item cache (GetItem/BatchGetItem by key) and a query cache (Query/Scan by request parameters), each with its own TTL.
When is DAX a poor investment?: Write-heavy traffic, little read repetition, or strong-consistency requirements, those reads bypass or barely use the cache, so you pay for little benefit.

Sources

Open the SysPad canvas · Official DynamoDB Accelerator (DAX) documentation