DynamoDB Advanced Features: DAX, Streams & Global Tables
The DynamoDB features that support real production systems beyond basic reads and writes — DAX for microsecond caching, Streams for event-driven reactions to data changes, Global Tables for multi-region active-active replication, and backup/restore options.
Want a visual for this topic?
Generate a diagram tailored to DynamoDB Advanced Features: DAX, Streams & Global Tables — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what DAX caches, and why it cannot help with strongly consistent reads
- •Trace how a DynamoDB Streams + Lambda trigger pipeline reacts to a table change end to end
- •Explain how Global Tables achieve multi-region writes and how AWS resolves write conflicts
- •Compare Point-in-Time Recovery to on-demand backups and choose correctly for a given scenario
What is it?
This topic covers four DynamoDB features used once an application needs more than basic key-value reads and writes: DAX (DynamoDB Accelerator), an in-memory caching layer purpose-built for DynamoDB; DynamoDB Streams, a change log that captures every item-level modification and can trigger downstream processing; Global Tables, which replicate a table across multiple AWS Regions with multi-region active-active writes; and DynamoDB's backup and restore options, including Point-in-Time Recovery and on-demand backups.
Why it exists
Even with DynamoDB's already-fast single-digit-millisecond latency, some workloads (like a real-time bidding system or a gaming leaderboard under extreme read load) need microsecond-level response times that a network round-trip to DynamoDB itself can't achieve — DAX exists to close that gap. Many systems need to react to data changes as they happen (send a notification when an order is placed, update a search index when a product is edited) rather than polling for changes, which is what Streams enables. Global applications serving users on multiple continents need low-latency reads and writes from a nearby Region without manually building multi-region replication and conflict resolution themselves, which is what Global Tables provides. And any production data store needs a real backup and recovery story beyond 'hope nothing goes wrong.'
Problem it solves
DAX solves the microsecond-latency and read-heavy-hotkey problem (a single frequently-read item, like a popular product page, can be served from cache instead of hitting the table on every request). Streams solves the event-driven-reaction problem, letting downstream systems react to changes without polling. Global Tables solves multi-region low-latency access and disaster recovery (a full Region outage doesn't take down the application, since other Regions keep serving). Point-in-Time Recovery and on-demand backups solve accidental-deletion and corruption recovery scenarios that eventual-consistency replication alone doesn't protect against.
Intuition
DAX is like a barista who memorizes the ten most common orders and hands them over instantly without checking the register (the underlying table) each time — it only helps for things asked often enough to be worth memorizing, and it can occasionally be a few seconds behind what the register actually says (eventual consistency), which is fine for a coffee order but not for checking an exact bank balance. DynamoDB Streams is like a security camera that records every change made to a filing cabinet, and other systems can 'watch the footage' to react the instant something changes, instead of repeatedly walking over to check the cabinet themselves.
Analogy
Global Tables are like multiple branches of the same library that all stay synchronized: a reader can check out or return a book at whichever branch is closest to them (writes accepted in any Region), and every branch eventually reflects every other branch's changes. If two branches happen to update the very same book's record at nearly the same moment, the library system needs a rule for which update wins — DynamoDB uses 'last writer wins' based on timestamps for this, which is the tradeoff of allowing writes everywhere instead of routing all writes through one central branch.
Technical explanation
DAX only accelerates eventually consistent reads (and can accelerate strongly consistent reads by passing them through to the table, but without the caching benefit) — an application requiring strongly consistent reads on every request gets no latency benefit from DAX for those specific requests, which is a common exam trap. DynamoDB Streams captures item-level changes in near-real-time and retains them for 24 hours, exposed as a stream that Lambda can be configured to poll automatically as an event source, processing batches of change records as they arrive — a common pattern for keeping a search index, cache, or downstream system in sync with table changes. Global Tables use DynamoDB's Streams mechanism internally to propagate changes between Regions, and resolve concurrent writes to the same item using a last-writer-wins strategy based on internal timestamps, meaning applications needing strict conflict resolution beyond last-writer-wins must handle that logic themselves. Point-in-Time Recovery, once enabled, allows restoring a table to any second within the last 35 days without impacting the live table's performance, while on-demand backups are manually or scheduler-triggered full backups retained until explicitly deleted, useful for long-term retention or pre-migration snapshots.
Architecture
A gaming leaderboard uses DAX in front of its DynamoDB table specifically for the read-heavy 'top 100 scores' query, which is requested constantly but changes relatively rarely, cutting both latency and DynamoDB read costs significantly. Separately, a DynamoDB Streams + Lambda trigger watches an orders table and, on every new order, updates a denormalized OpenSearch index used for the application's search feature. For a globally distributed SaaS product, a Global Table replicates the users table across three Regions so users in each Region read and write to their nearest Region with low latency, and the application survives a full Regional outage by failing over to another Region.
Workflow
(1) Identify hot, read-heavy, cache-tolerant access patterns and front them with DAX, being explicit about which reads can tolerate eventual consistency. (2) Enable Streams on any table where downstream systems need to react to changes, and attach a Lambda trigger to process the change log. (3) For globally distributed applications, convert a table to a Global Table and verify the application can tolerate last-writer-wins conflict resolution for any item that might realistically be written concurrently from two Regions. (4) Enable Point-in-Time Recovery on any production table as a baseline safety net, and use on-demand backups for longer-term retention needs beyond the 35-day PITR window.
Example
An e-commerce platform enables DynamoDB Streams on its inventory table; a Lambda trigger consumes the stream and, whenever an item's stock count crosses zero, publishes an SNS notification that removes the item from the storefront's 'available' listing within seconds — no polling job checking stock levels on a timer is needed at all.
Real-world usage
DAX is commonly used for gaming leaderboards, ad-tech bidding systems, and any workload with a small number of extremely hot keys under massive read concurrency. DynamoDB Streams + Lambda is one of the most common event-driven patterns on AWS, used for search index synchronization, audit logging, and cross-service data propagation. Global Tables are used by any genuinely globally distributed application needing low-latency multi-region access or Region-level disaster recovery without building custom replication.
Trade-offs
DAX trades eventual consistency (for cached reads) and additional infrastructure cost for a dramatic latency improvement on hot-key read-heavy workloads — worth it only when that specific latency matters and eventual consistency is acceptable. Global Tables trade increased write cost and last-writer-wins simplicity for global low-latency access and Region-level resilience — the right call for genuinely global applications, unnecessary complexity and cost for a single-Region product. Point-in-Time Recovery is close to a strictly-beneficial default (minimal cost, zero performance impact) and is generally worth enabling on every production table.
Visual explanation
Picture DAX as a cache layer sitting directly in front of a DynamoDB table, transparent to the application except for using the DAX SDK client instead of the standard DynamoDB client; a read that hits the cache returns in microseconds, a cache miss falls through to the table itself and populates the cache for next time. Picture Streams as a continuously appended, ordered log attached to a table, where each entry captures an item's before/after image for every insert, update, or delete, which a Lambda function (or other consumer) can subscribe to and process incrementally. Picture Global Tables as the same table existing in multiple Regions simultaneously, each Region accepting both reads and writes, with changes propagating to every other Region typically within a second.
Advantages
- —
DAX delivers microsecond read latency for cache-hit requests with minimal application changes (swap SDK clients)
- —
Streams enables clean, decoupled event-driven architectures without polling, and integrates natively with Lambda as an event source
- —
Global Tables provide multi-region active-active replication and Region-level disaster recovery with no custom replication code
- —
Point-in-Time Recovery has zero performance impact on the live table and covers any second in the last 35 days
Disadvantages
- —
DAX only benefits eventually consistent reads, and adds its own cluster to provision and pay for
- —
Streams retains data for only 24 hours, meaning a downstream consumer that falls too far behind loses those change records permanently
- —
Global Tables' last-writer-wins conflict resolution isn't appropriate for every data model — applications needing stricter conflict handling must build it themselves
- —
Global Tables roughly multiply write costs by the number of participating Regions, since every write replicates everywhere
Common mistakes
- —
Assuming DAX accelerates all reads, including strongly consistent ones, and being surprised when latency-sensitive strongly-consistent queries see no improvement
- —
Not consuming a DynamoDB Stream fast enough, silently losing change records once they age out past the 24-hour retention window
- —
Enabling Global Tables without checking whether the application's data model can tolerate last-writer-wins conflict resolution for concurrently-written items
- —
Treating Point-in-Time Recovery as a substitute for on-demand backups when longer-than-35-day retention is required for compliance or audit reasons
In the AWS Console
- 1
DynamoDB → Tables → [table] → Additional settings → DynamoDB Accelerator (DAX)
Create a DAX cluster associated with the table, then update the application to use the DAX SDK client for the specific access patterns you want cached.
Only eventually consistent reads benefit from the cache — mixed-consistency applications should route requests deliberately.
- 2
DynamoDB → Tables → [table] → Exports and streams → Turn on
Enable DynamoDB Streams (choosing the stream view type, e.g. New and old images), then create a Lambda trigger against the stream.
Choose the stream view type based on what the consumer needs — 'New and old images' is the most common choice since it supports the widest range of downstream logic.
- 3
DynamoDB → Tables → [table] → Global tables → Create replica
Add one or more additional Regions as replicas; DynamoDB Streams is enabled automatically to support the underlying replication.
Verify the application's write patterns can tolerate last-writer-wins conflict resolution before enabling this in production.
🎤 Interview questions
Why doesn't DAX help a request that requires a strongly consistent read? (Listen for: DAX's cache serves eventually consistent data by design; strongly consistent reads bypass the cache and go straight to the table, gaining no latency benefit.)
Walk through a DynamoDB Streams + Lambda event-driven pipeline end to end. (Listen for: a table change appends a record to the stream, Lambda is configured as an event source polling the stream, batches of change records trigger the function, which processes each item's before/after image.)
How does DynamoDB resolve two concurrent writes to the same item in different Regions of a Global Table? (Listen for: last-writer-wins, based on internal timestamps — applications needing stricter conflict resolution must implement it themselves.)
What's the difference between Point-in-Time Recovery and an on-demand backup for DynamoDB? (Listen for: PITR = continuous, any-second restore within a rolling 35-day window, zero performance impact; on-demand backup = manually/scheduler-triggered full snapshot retained until explicitly deleted, better for long-term/compliance retention.)
Why would enabling Global Tables roughly multiply a table's write costs? (Listen for: every write is replicated to every participating Region, so N Regions means the write is effectively billed N times across the replicated table.)
📂 Subtopics
DAX: When Microsecond Reads Actually Matter
What DAX caches, its consistency limitation, and the specific workload shapes where it earns its cost.
~10 min
Streams as the Engine Behind Global Tables
How the same Streams mechanism that powers event-driven Lambda triggers is also what makes Global Tables' replication work.
~10 min