DynamoDB on-demand vs provisioned capacity, and when to use DAX

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. A read-heavy application reads the same small set of items from an Amazon DynamoDB table thousands of times a second. Every read sets ConsistentRead to true, although the application can tolerate data that is a few seconds old for all but one of its operations. The team puts a three-node DAX cluster in front of the table and measures no improvement in read latency. The team needs read latency to improve while the one operation that requires current data still receives it. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design High-Performing Architectures building.

   Not that one: A is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

   The answerA.Keep ConsistentRead true only on the operation that needs it, and let other reads go eventually consistent through DAX.The reads are asking for something DAX is not able to give. "DAX passes strongly consistent read requests to DynamoDB. When it receives a response from DynamoDB, DAX returns the results to the client, but it does not cache the results. DAX can't serve strongly consistent reads by itself because it's not tightly coupled to DynamoDB." Every read in this application therefore travels to the table and back with an extra hop through the cluster, and nothing is ever cached to be hit later - which is why the measurement shows no improvement rather than a partial one. The application already tolerates slightly stale data everywhere but one operation, so dropping ConsistentRead on those reads is what lets the item cache do any work at all. Cluster size is the natural first suspect and is the wrong one here: a bigger cache is still a cache that is never read.Your answerB.Raise the item cache TTL on the DAX cluster, so that cached items survive long enough to be read again by the application.A TTL governs how long an entry lives. Nothing is being stored for it to govern.Your answerC.Turn on DynamoDB Accelerator write-through caching for the table, so that reads are served from the item cache immediately after every write.Write-through is not a setting. DAX is a write-through cache by design, and it is reads, not writes, that are bypassing it.Your answerD.Add nodes to the DAX cluster and move to a larger node type, so that the working set fits in the item cache and hit rates improve.Enlarges a cache that is never consulted. A strongly consistent read is not answered from the item cache however large it is.

   Written from docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html

2. A leaderboard page runs the same DynamoDB Query through a DAX cluster every time a player opens it. Scores are written through the same DAX client. Players report that a score they have just posted does not appear on the leaderboard for several minutes, although reading the score item directly returns the new value at once. The team needs a newly posted score to appear on the leaderboard promptly. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design High-Performing Architectures building.

   Not that one: C is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Write the scores directly to DynamoDB instead of through DAX, so that the Query results are refreshed as each score lands.Makes the staleness worse. A write that bypasses DAX does not refresh the query cache either, and the item cache stops being current as well.Your answerB.Lower the DAX item cache TTL, because the Query is served from the item cache and its entries are stale.Names the wrong cache. Reading the item directly already returns the new value, which is the item cache working correctly.The answerC.Lower the TTL on the DAX query cache, because a write updates the item cache and leaves cached Query result sets untouched.The two caches are separate, and only one of them is being updated. "Every DAX cluster has two distinct caches - an item cache and a query cache", and a write through DAX touches the first only: "Every write to DAX alters the state of the item cache. However, writes to the item cache don't affect the query cache." That is exactly the symptom the players describe, since the score item itself is current while the leaderboard is not. Cached result sets are not invalidated by a write at all - "Updates to the item cache, or to the underlying DynamoDB table, do not invalidate or modify the results stored in the query cache" - so the only thing that refreshes a Query is the expiry of its own TTL. Shortening that TTL is the setting that decides how stale a leaderboard may be.Your answerD.Add nodes to the DAX cluster, because replication of the new score between nodes is what players are waiting for.Replication between nodes "is eventually consistent and usually takes less than one second to complete", not several minutes.

   Written from docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html

3. An Amazon DynamoDB table in on-demand mode has a maximum write throughput of 3,000 write request units per second, set as a cost guard. Its previous peak was about 2,500 writes per second of 1 KB items. A product launch will send about 20,000 writes per second from its first minute. The table must stay in on-demand mode, and launch writes must not be throttled. Which combination of steps should a solutions architect take to meet these requirements? (Select TWO.)

   Right. In the game that’s Renown for your Design High-Performing Architectures building.

   Not that one: A,B is right. In the game your Design High-Performing Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Increase the table's warm throughput to 20,000 write units per second before the launch so that the table can take that rate instantly.Your answerB.Raise the table's maximum write throughput setting above 20,000 write request units per second before the launch.Your answerC.Switch the table to provisioned capacity mode for the launch day, with 20,000 write capacity units to cover 20,000 writes per second.The company requires on-demand mode, and a switch to provisioned mode breaks that requirement.Your answerD.Request a Service Quotas increase for the account's table-level write throughput quota before the launch.20,000 writes per second is within the default 40,000 table-level throughput quota, and the quota is not what caps this table; its own maximum throughput setting does.Your answerE.Rely on on-demand mode to add capacity as the launch traffic arrives, because on-demand tables need no capacity planning for new peaks.On-demand instantly handles up to double the previous peak. 20,000 writes per second in the first minute is eight times the 2,500 peak, and growth past double within 30 minutes can be throttled.

   Written from docs.aws.amazon.com/amazondynamodb/latest/developerguide/warm-throughput.html