DynamoDB Global Tables & DAX Caching
Recap: Where We Left Off
Day 24 established that DynamoDB's performance story is really a partitioning story. The table's advertised read and write capacity units are an aggregate budget, but the physical unit that enforces throughput is the partition, and each partition has its own ceiling. A partition key with low cardinality — a status field with five possible values, a date string, a tenant ID that dominates traffic — concentrates writes onto a handful of partitions and throttles them even when the table as a whole is nowhere near its provisioned capacity. That is the hot-key failure mode, and it is invisible in table-level CloudWatch metrics until you look at the per-partition dimensions or the throttled-request counters.
Today extends that model outward in two directions at once. Global Tables take the single-region table you partitioned carefully and replicate it into multiple regions as a multi-active, multi-writer system, which means the partition-key design now has to survive conflict resolution as well as throughput. DAX takes the same table and puts an in-memory cache in front of it, which changes the read path but not the write path — and therefore does not rescue a badly designed key. Both features are extensions of the partitioning and capacity-mode decisions from Day 24, and both are commonly tested as distractors against each other.
Foundations You'll Need Today
Today's material sits on top of a handful of DynamoDB and AWS fundamentals that the rest of this page will use without stopping to define them. If you have not worked with DynamoDB hands-on, these four ideas are the ones worth having straight before the architecture discussion starts.
Partition keys and why they decide everything
A DynamoDB table is not stored as one big file on one machine. AWS splits the table's data across many physical servers, called partitions, and the value of the partition key is what decides which partition a given item lands on. Think of it like a filing cabinet with many drawers: the partition key is the label that tells DynamoDB which drawer to open. If you choose a key with lots of distinct values — a user ID, an order ID — items spread evenly across the drawers and each drawer carries a fair share of the traffic. If you choose a key with only a few distinct values, or one value that dominates, then most of your requests pile into a single drawer while the others sit idle. That single overloaded drawer is called a hot partition, and it is the root cause of most DynamoDB performance problems. This matters today because Global Tables replicates the table's partitions into every region, so a badly chosen key does not get better when you add regions — it gets copied.
Read and write capacity units, and the two capacity modes
DynamoDB charges for throughput rather than for servers. A read capacity unit (RCU) is roughly one strongly consistent read per second of an item up to 4 KB, and a write capacity unit (WCU) is roughly one write per second of an item up to 1 KB. You buy that throughput in one of two ways. In provisioned mode you declare how many RCUs and WCUs the table should have, and you can attach auto scaling so the number rises and falls with demand; you pay for what you reserve. In on-demand mode you declare nothing and DynamoDB scales automatically, charging per request instead. The tradeoff is predictability versus convenience: provisioned is cheaper at a steady, known load, and on-demand is simpler and absorbs unpredictable spikes without you having to guess. Today's material refers to both modes repeatedly, because each Global Tables replica has its own capacity mode and because replicated writes consume write capacity in the receiving region.
Eventual versus strongly consistent reads
When you write an item to DynamoDB, the write is acknowledged once it is durably stored — but if the table keeps more than one copy of the data for availability, a read that arrives immediately afterward might hit a copy that has not yet caught up. A strongly consistent read waits for the latest copy and always returns the most recent write; an eventually consistent read takes whichever copy answers first and may briefly return older data. Strongly consistent reads cost twice as much in capacity units and are slower, which is why eventually consistent is the default. This distinction is the hinge of today's whole discussion: cross-region replication in Global Tables is asynchronous, so it is inherently eventually consistent, and DAX can only cache eventually consistent reads because a cached value cannot be guaranteed to be the latest one.
Regions and why distance costs latency
An AWS region is a separate geographic cluster of data centers — us-east-1 in Virginia, eu-central-1 in Frankfurt, and so on. Resources you create live in one region unless you deliberately copy them to another. Data travelling between regions crosses real physical distance and real network hops, which takes measurable time: a round trip between Virginia and Frankfurt is on the order of a tenth of a second, which is enormous compared to the single-digit milliseconds a request takes inside one region. That gap is the entire reason Global Tables exists — it lets a user in Europe read and write against a copy of the data that lives in Europe, instead of every request making the trip to Virginia and back.
With that grounding, here is why Global Tables and DAX exist and what problem each one actually solves.
1. Why This Is on the Exam
SAP-C02's resilient architectures domain is built around a small number of recurring scenario shapes, and "global application, users in multiple continents, needs low-latency reads and writes, must survive a regional outage" is one of the most common. The exam wants to know whether you can distinguish between the tools that solve latency, the tools that solve availability, and the tools that solve both — and whether you understand that a single service can be the right answer for one of those and the wrong answer for the other. DynamoDB Global Tables and DAX sit on opposite sides of that line, which is precisely why they appear together in so many practice questions.
The architectural problem Global Tables solves is that a single-region DynamoDB table forces every write from every continent through one region. You can put CloudFront or a read replica in front of reads, but writes still cross an ocean, and a regional failure takes the whole system down. Global Tables removes both constraints by making every participating region a first-class writer against a locally hosted replica, with asynchronous replication between them. The problem DAX solves is narrower and cheaper: a read-heavy workload where the same items are requested over and over, and the single-digit-millisecond latency of a DynamoDB GetItem is still too slow or too expensive at the request volume involved.
Both features map to Domain 2 (Design Resilient Architectures) and Domain 3 (Design High-Performing Architectures), with Global Tables leaning harder on the resilience side and DAX leaning harder on performance. The exam rarely asks "what is DAX" — it asks you to choose between DAX, ElastiCache, DynamoDB Accelerator, and application-level caching for a described workload, and the discriminator is almost always whether the workload needs the DynamoDB API surface, whether the data is hot and read-heavy, and whether the cache must be strongly consistent with the table. Getting those three questions right is most of the battle.
2. How Global Tables and DAX Actually Work
Global Tables is built on DynamoDB Streams. When you add a replica region to a table, DynamoDB creates a replica table in that region and establishes a bidirectional replication relationship between the two. Every write to any replica is captured by that replica's stream and applied to the other replicas asynchronously, typically within about a second. The replication is multi-active: there is no primary region and no failover step. A client in Frankfurt writes to the Frankfurt replica and reads from the Frankfurt replica, and the same is true for a client in Oregon. This is the property that makes Global Tables different from Aurora Global Database, where one region is the writer and the others are read-only until a promotion event.
Because writes can happen in two places at once, Global Tables needs a conflict resolution rule, and it uses last-writer-wins at the item level. Each write carries a timestamp, and when two replicas have divergent versions of the same item, the one with the later timestamp wins and is replicated to the other. The important detail is that the comparison is per item, not per attribute — a write that updates only the status attribute of an item will overwrite a concurrent write that updated only the lastSeen attribute of the same item, because the whole item is the unit of conflict resolution. This is why the standard guidance is to design for non-overlapping write sets, or to use a composite key that gives each writer its own item.
DAX works differently and much more simply. It is a cluster of cache nodes that speaks the DynamoDB API. Your application points its DynamoDB client at the DAX cluster endpoint instead of the regional DynamoDB endpoint, and DAX transparently handles the caching. On a read, DAX checks its in-memory cache; on a hit it returns the item without touching DynamoDB, and on a miss it reads from DynamoDB, populates the cache, and returns the item. On a write, DAX writes through to DynamoDB and updates or invalidates the cached copy. The application code does not change beyond the endpoint, which is the main reason DAX is attractive compared to bolting on ElastiCache — there is no cache-key design, no serialization layer, and no separate invalidation logic to write.
The consistency model is where DAX gets subtle. DAX supports eventually consistent reads by default, and it can also serve strongly consistent reads, but a strongly consistent read bypasses the cache entirely and goes to DynamoDB. That means the cache only ever holds eventually consistent data, and any read that requires strong consistency pays full DynamoDB latency. If your workload is dominated by strongly consistent reads, DAX will not help you, and that is a fact the exam likes to test.
3. The Core Decision Boundary
The fork that most scenario questions hinge on is whether the problem is about where the data lives or how fast it is read. Global Tables changes the topology of the data — it puts a writable copy in each region so that latency is local and a regional failure does not take the system down. DAX changes the read path — it puts a cache in front of a single table so that repeated reads of the same items are cheaper and faster. These are orthogonal concerns, and a workload can legitimately need both, neither, or exactly one. The exam's job is to make you pick the one that matches the stated constraint.
The second fork, which is easy to miss, is whether the workload can tolerate eventual consistency. Global Tables is inherently eventually consistent across regions — a write in Frankfurt is not visible in Oregon until replication completes, typically within a second but not guaranteed. DAX is eventually consistent by default and cannot cache strongly consistent reads. If the scenario says "the application must read its own writes immediately from any region," neither feature alone satisfies it, and the correct answer is usually to route that specific read to the region that performed the write, or to use a strongly consistent read that bypasses DAX.
| Constraint in the scenario | Global Tables | DAX |
|---|---|---|
| Users on multiple continents need low-latency writes | Yes — local write to the nearest replica | No — writes still go to the single table's region |
| Same items read thousands of times per second | No — replication does not reduce read cost | Yes — cache hit avoids the DynamoDB read entirely |
| Survive a full regional outage with no failover step | Yes — every region is already active | No — DAX is regional and does not replicate |
| Strongly consistent reads required | No — cross-region replication is async | No — strongly consistent reads bypass the cache |
| Application cannot be modified beyond the client endpoint | No — requires replica configuration and key review | Yes — DAX is API-compatible with DynamoDB |
| Cost is the primary constraint | No — you pay for storage and replicated write capacity in every region | Sometimes — DAX nodes cost money but can reduce read RCU spend |
The practical rule that falls out of this table is: if the scenario mentions geography, disaster recovery, or write latency across regions, think Global Tables. If it mentions hot items, read amplification, or microsecond latency on repeated reads, think DAX. If it mentions both, the answer is usually Global Tables plus DAX in each region, and the exam will expect you to say so without hesitation.
4. Configuration Modes and Their Tradeoffs
Global Tables has a small number of configuration decisions, but each one has a real cost. The first is which regions participate. Every replica region stores a full copy of the table's data and consumes write capacity units for replicated writes, so adding a region roughly multiplies your storage cost and adds to your write bill. The second is the capacity mode of each replica. A replica can be on-demand or provisioned, and the mode is set per replica, which means you can run the primary region provisioned with auto scaling and a low-traffic replica on-demand. The third is whether the table uses a version of Global Tables that requires you to enable DynamoDB Streams explicitly — the current version manages streams for you, but older tables and older exam questions sometimes assume you configure them by hand.
The most consequential configuration decision is not a setting at all; it is the partition key design. Because conflict resolution is last-writer-wins at the item level, a key that causes two regions to write the same item concurrently will silently lose one of those writes. The standard mitigation is to make the key region-scoped or writer-scoped — for example, a composite key of userId plus region, or an item-per-event model where each write creates a new item rather than updating an existing one. This is the same partitioning discipline from Day 24, now with a correctness consequence rather than just a throughput one.
DAX's configuration decisions are about cluster shape and consistency. A DAX cluster has one primary node and zero or more read replicas, and the primary handles both reads and writes while replicas handle reads. The cluster is placed in a VPC and accessed through a cluster endpoint, so the application must run inside the VPC or have connectivity to it. Node type determines memory and therefore how much of the working set fits in cache; if the hot set exceeds the cluster's memory, hit rate collapses and DAX becomes a latency tax rather than a benefit. TTL settings on the table interact with DAX as well — expired items are not served from cache, but the cache does not proactively evict them, so a read after expiry will miss and repopulate.
| Knob | Option A | Option B | What it costs you |
|---|---|---|---|
| Global Tables replica count | Two regions | Three or more regions | Storage and replicated write capacity scale with each added region |
| Replica capacity mode | On-demand | Provisioned with auto scaling | On-demand is simpler but more expensive at steady load |
| Conflict exposure | Region-scoped keys | Shared keys across regions | Shared keys risk silent last-writer-wins data loss |
| DAX cluster size | Single node | Primary plus replicas | Replicas add cost and read throughput but not write throughput |
| DAX read consistency | Eventually consistent (cached) | Strongly consistent (bypasses cache) | Strong reads get no latency benefit from DAX |
5. Sizing, Limits and Quotas
The numbers that matter for Global Tables are mostly about replication behavior rather than hard caps. Replication between regions is asynchronous and typically completes within about a second under normal conditions, but AWS does not offer a latency SLA on it, and the exam will not ask you to promise one. Each replica region must have enough write capacity to absorb the replicated writes in addition to its own local writes, which is why a table that is provisioned tightly in one region can throttle after you add a replica. The practical sizing move is to provision each replica for local writes plus replicated writes, or to use on-demand mode and let the table absorb the burst.
Global Tables requires that the table have a DynamoDB Streams-enabled configuration and that all replicas share the same key schema and the same set of global secondary indexes. You cannot add a GSI in one region and not another; the schema is replicated. Item size limits are unchanged from single-region DynamoDB — 400 KB per item — and the same applies to the replicated copy. There is no separate quota for the number of regions, but each region you add is a full copy of the data, so the storage cost is linear in the number of replicas.
DAX's sizing is dominated by memory. The cluster's total cache memory is the sum of the node memory across the cluster, and the working set that matters is the set of items that are read frequently enough to stay hot. If the hot set fits comfortably, hit rates in the high nineties are achievable; if it does not, the cache thrashes and you get the worst of both worlds — DAX latency plus DynamoDB latency on every miss. Node types range from small (a few gigabytes) to large (hundreds of gigabytes), and the cluster can be scaled by adding nodes, but the cache is not persistent across node replacement, so a node failure means a cold cache until it warms again. DAX also has a per-item size limit for cached items — items larger than the limit are not cached and always go to DynamoDB.
| Dimension | Global Tables | DAX |
|---|---|---|
| Replication latency | Typically under a second, no SLA | Not applicable — DAX is regional |
| Item size limit | 400 KB (unchanged from DynamoDB) | Items above the cache limit are not cached |
| Schema constraints | Identical key schema and GSIs in every replica | None beyond DynamoDB's own |
| Capacity impact | Each replica consumes write capacity for replicated writes | Reduces read capacity consumption on cache hits |
| Scaling unit | Regions (each a full data copy) | Nodes (each adds memory and read throughput) |
6. Failure Modes and What They Look Like in Production
The signature Global Tables failure is silent data loss from concurrent writes to the same item in different regions. There is no error, no exception, and no alarm — one write simply wins and the other is overwritten during replication. The symptom is a user reporting that an update they made "didn't save," usually in a pattern that correlates with two regions being active at the same time. The first diagnostic move is to look at the write pattern: are two regions writing the same item within the replication window? If so, the fix is a key redesign, not a configuration change. This is the failure mode that makes Global Tables dangerous for counters, balances, and any item that multiple regions update in place.
The second failure mode is replication lag under load. When a region is absorbing a large write burst, replication to other regions can fall behind, and reads in the remote region return stale data for longer than the usual sub-second window. The symptom is a read-after-write inconsistency that appears only during traffic spikes. CloudWatch exposes replication latency metrics per replica, and the first diagnostic move is to compare those metrics against the application's tolerance for staleness. If the application cannot tolerate the lag, the answer is usually to route the read to the region that performed the write rather than to try to tune replication.
DAX's signature failure is a cold cache after a node replacement or cluster restart. Because the cache is in memory and not persisted, a node failure means every subsequent read misses until the hot set is repopulated, and during that window the application sees DynamoDB latency plus the DAX hop. The symptom is a latency spike that correlates with a DAX node event rather than with DynamoDB throttling. The second DAX failure is a working set that exceeds cluster memory, which produces a persistently low hit rate and a latency profile that is worse than going straight to DynamoDB. The diagnostic is the cache hit rate metric; if it is not high, the cluster is undersized for the workload.
A third failure mode, shared by both features, is the assumption that they solve a problem they do not. Global Tables does not make a hot partition go away — it replicates the hot partition into every region. DAX does not make a write-heavy workload faster — writes still go to DynamoDB and still consume write capacity. Scenarios that describe a write-heavy workload with a hot key and expect either feature to fix it are testing whether you understand the boundary.
7. Operational and SRE Angle
For Global Tables, the metrics that matter are replication latency per replica, the throttled-write counters in each region, and the consumed write capacity in each region relative to its provisioned capacity. The alarm shape is straightforward: alert when replication latency exceeds the application's staleness tolerance, and alert when any replica's write throttling is non-zero. The runbook for a replication lag alarm is to check whether the lagging region is under a write burst, whether its provisioned capacity is adequate for local plus replicated writes, and whether the application can be temporarily routed away from the lagging region for reads that require freshness.
For DAX, the metrics that matter are cache hit rate, cache evictions, and the latency of the DAX cluster itself. A hit rate that drops below the expected baseline is the leading indicator of a working-set problem, and it usually precedes a user-visible latency regression by enough time to react. The runbook for a hit-rate drop is to check whether the hot set has grown (a new feature reading a wider key range, a traffic shift), whether the cluster has lost a node, and whether the node type is still appropriate. Because DAX is regional, there is no cross-region failover story — the operational question is whether the cluster is healthy in its region, not whether it can survive losing one.
The SLO implication of Global Tables is that you cannot promise strong read-after-write consistency across regions, so any SLO that depends on it must be scoped to a single region. The SLO implication of DAX is that read latency SLOs are only achievable for the cached portion of the workload, so the SLO should be expressed against the hit-rate-adjusted latency rather than a flat number. Both features change what you can promise, and the operational discipline is to write the SLO against what the architecture actually delivers rather than what the marketing page implies.
8. Edge Cases and Exam Gotchas
The single most-tested gotcha is that Global Tables conflict resolution is last-writer-wins at the item level, not the attribute level. A question that describes two regions updating different attributes of the same item and asks what happens is testing exactly this. The answer is that one of the two writes is lost entirely, and the fix is a key design that prevents concurrent writes to the same item. A related gotcha is that the timestamp used for conflict resolution is generated by DynamoDB, not by the client, so clock skew on the application side does not affect the outcome — but it also means you cannot influence which write wins by adjusting client clocks.
The second gotcha is that DAX does not cache strongly consistent reads. A scenario that says "the application requires strongly consistent reads and low latency" is a trap: DAX cannot deliver both, because the strongly consistent read path bypasses the cache. The correct answer is usually to use DAX for the eventually consistent reads and accept DynamoDB latency for the strongly consistent ones, or to redesign the access pattern so that strong consistency is not required.
The third gotcha is that Global Tables is not a backup. Replication is bidirectional and near-real-time, so a bad write in one region propagates to every other region within about a second. If the scenario asks for protection against accidental deletion or corruption, the answer is point-in-time recovery or AWS Backup, not Global Tables. The fourth gotcha is that DAX is not a multi-region service — it is a regional cache in front of a regional table, and if the table is a Global Table, you need a DAX cluster in each region to get the latency benefit locally. The fifth is that DAX does not reduce write capacity consumption; writes still go to DynamoDB and still cost WCUs.
9. This vs. the Services It Gets Confused With
Global Tables is most often confused with Aurora Global Database and with DynamoDB backups. Aurora Global Database also provides cross-region replication, but it is single-writer — one region accepts writes and the others are read-only until a promotion, which takes on the order of a minute. Global Tables is multi-active, with every region accepting writes continuously and no promotion step. If the scenario says "writes must be accepted in every region simultaneously," the answer is Global Tables; if it says "a relational database with a standby region that can be promoted," the answer is Aurora Global Database. The confusion with backups is simpler: Global Tables replicates changes, including bad ones, so it is not a recovery mechanism.
DAX is most often confused with ElastiCache and with application-level caching. ElastiCache gives you a general-purpose cache that can hold anything, but it requires you to design cache keys, handle serialization, and write invalidation logic — and it does not speak the DynamoDB API. DAX is DynamoDB-specific and API-compatible, which means the application change is a single endpoint swap. The tradeoff is that DAX only caches DynamoDB items and only in the shape DynamoDB returns them, so it cannot cache computed results or joined data. If the scenario describes caching a DynamoDB item read, DAX is the lower-effort answer; if it describes caching a computed response or a cross-service aggregate, ElastiCache is the right tool.
| Service | What it does | Pick it when… |
|---|---|---|
| DynamoDB Global Tables | Multi-active cross-region replication of a DynamoDB table | Writes must be accepted in multiple regions and the app must survive a regional outage |
| Aurora Global Database | Cross-region replication with a single writer region | The workload is relational and a promoted standby region is acceptable |
| DAX | In-memory, DynamoDB-API-compatible read cache | Hot items are read repeatedly and the app can tolerate eventual consistency |
| ElastiCache | General-purpose in-memory cache | You need to cache computed results, sessions, or non-DynamoDB data |
| DynamoDB point-in-time recovery | Continuous backup with restore to any point in the last 35 days | You need protection against bad writes or accidental deletion |
Hands-on Lab: Two-Region Global Table with a DAX Read Cache (60 min)
This lab builds a two-region Global Table, exercises the last-writer-wins conflict behavior deliberately, then adds a DAX cluster in one region and measures the read-latency difference. You will need two AWS regions, an IAM role with DynamoDB and DAX permissions, and a way to run a small script (CloudShell or a local machine with the AWS CLI and Python).
- In region A, create a DynamoDB table named
leaderboardwith a partition keyplayerId(string) and no sort key. Use on-demand capacity mode so you do not have to reason about capacity during the lab. Wait for the table to become active. - Enable DynamoDB Streams on the table with
NEW_AND_OLD_IMAGES. Global Tables manages streams for you in the current version, but enabling them explicitly makes the replication mechanism visible and is a useful habit when reading older documentation. - Add a replica in region B. In the console this is the Global Tables tab; via the CLI it is
update-table --replication-group. Wait until the replica status is active in both regions. Note that the table now exists in both regions with the same key schema. - Write a script that inserts a single item with
playerId = "p1"and ascoreattribute, writing to region A. Then read the same item from region B and confirm it appears within a second or two. This is the replication path working as designed. - Now deliberately create a conflict. From two terminals, write to the same item in region A and region B within the same second, setting
scoreto two different values. Wait five seconds, then read the item from both regions. Observe that both regions converge on one value and that the other write is gone. Record which value won and reason about why — the timestamp is generated by DynamoDB, so the outcome is not something you control from the client. - Redesign the key to avoid the conflict. Change the table to use a composite key of
playerId(partition) andregion(sort), or create a new table with that schema. Repeat the concurrent write from step 5, writing to different sort-key values in each region. Confirm that both writes survive and that each region can read both items. This is the key-design fix that the exam expects you to propose. - Create a DAX cluster in region A. Use a small node type, place it in the default VPC, and wait for it to become available. Note the cluster endpoint.
- Modify your script to point the DynamoDB client at the DAX endpoint instead of the regional endpoint. Run a loop that reads the same item 1,000 times and record the average latency. Then run the same loop against the regional DynamoDB endpoint and compare. The DAX path should be measurably faster once the cache is warm.
- Inspect the DAX cache hit rate metric in CloudWatch after the loop. Then run a loop that reads 10,000 distinct items once each and observe the hit rate collapse. This demonstrates the working-set sizing problem: DAX only helps when the same items are read repeatedly.
- Finally, run a strongly consistent read through the DAX client and confirm that it returns the correct value but does not benefit from the cache. This is the consistency boundary from section 3, made concrete.
Clean up by deleting the DAX cluster, then the replica, then the table. Leaving a Global Table running in two regions is a small but real ongoing cost, and the habit of tearing down lab resources is worth building now.
Scenario Question Drills (20 min)
Q1. A gaming leaderboard needs microsecond read latency for the same items requested extremely frequently. What should sit in front of DynamoDB?
Q2. An application writes to a DynamoDB table in us-east-1 and us-west-2 simultaneously. Two regions update the same item within the same second, one changing status and the other changing lastSeen. What happens?
Q3. A team wants a DynamoDB table that accepts writes in three regions with no failover step and survives the loss of any one region. Which feature provides this?
Q4. A read-heavy application requires strongly consistent reads and low latency. The team proposes DAX. What is the problem?
Q5. A Global Table is provisioned tightly in its primary region. After adding a second region, the primary region starts throttling writes even though local write volume has not changed. Why?
Q6. A DAX cluster's cache hit rate has dropped from the high nineties to under 40% over the past week, and read latency has increased. What is the most likely cause?
Q7. A team needs protection against an application bug that deletes items from a DynamoDB table. They propose enabling Global Tables so a second region has a copy. Why is this wrong?
Q8. An application runs in three regions against a Global Table and needs local read latency in each. The team has deployed a DAX cluster in one region only. What is the gap?
Q9. A workload writes 5,000 items per second and reads each item once. The team proposes DAX to reduce DynamoDB read cost. What is the flaw in this plan?
Q10. A Global Table's replication latency metric spikes to several seconds during a traffic burst in one region. Reads in the other region return stale data. What is the first diagnostic move?
Q11. Which statement about Global Tables and DynamoDB Streams is correct?
Q12. A team wants to cache computed API responses that aggregate data from DynamoDB and two other services. They propose DAX. What is the correct recommendation?
Q13. A Global Table has a global secondary index in the primary region. What must be true of the replica regions?
Q14. A DAX cluster loses a node and is replaced. Users report a latency spike for several minutes afterward. What explains this?
Q15. A scenario describes a write-heavy workload with a hot partition key and asks whether Global Tables or DAX will fix the throttling. What is the correct answer?
Peek into Tomorrow
Everything covered here assumed that the data itself is the thing being replicated and cached — items in a table, moved between regions, held in memory. But a large fraction of the data an AWS application actually stores is not in a database at all. It is in S3: logs, backups, media, model artifacts, data-lake files, and the long tail of objects that are written once and read rarely or never. That data has the same cost-versus-latency tension we have been working with all week, but S3 exposes it as a much wider set of explicit choices rather than a single capacity mode.
The open question today leaves unresolved is what happens when the access pattern of an object is not known in advance. DynamoDB's on-demand mode is a single toggle that absorbs unpredictability, but S3 has no equivalent single answer — it has a ladder of storage classes from Standard down to Glacier Deep Archive, each with its own retrieval latency and availability characteristics, and a lifecycle rule engine that moves objects between them on a schedule. The interesting design problem is whether you can express an unknown access pattern as a lifecycle policy, or whether you need Intelligent-Tiering to make the decision per object. Tomorrow's material on lifecycle transition rules and CRR versus SRR is where that question gets answered.
Sources
- Amazon DynamoDB Developer Guide — Global Tables
- DynamoDB Developer Guide — How Global Tables Works (conflict resolution)
- DynamoDB Developer Guide — DynamoDB Accelerator (DAX)
- DynamoDB Developer Guide — DAX Concepts and Cluster Architecture
- DynamoDB Developer Guide — DAX and Read Consistency
- DynamoDB Developer Guide — Service Quotas
- DynamoDB Developer Guide — Point-in-Time Recovery
- Amazon CloudWatch — Metrics Reference for DynamoDB and DAX
- AWS Database Blog — Multi-Region Active-Active Applications with Global Tables