DynamoDB Last Name Update Issue
Question
Consider the following scenario: Id First Name Last Name 1 John Abraham I have stored this data in a DynamoDB table.
After running an update, I change the Last Name from “Abraham” to “Mathew”
When John reads his data immediately after the update, he still sees his Last Name as Abraham rather than Mathew.
What is the possible reason?
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.Answer: B.
DynamoDB chooses Performance over Consistency while delivering reads.
Using this model, during a read, DynamoDB will look for the nearest & most available storage location for fulfilling the read request.
DynamoDB stores three geographically distributed replicas of each table.
It may so happen that the storage location where DynamoDB performs the read would not have been updated with the latest data.
Strong consistency involves multiple reads to ensure that the latest update is always available sacrificing Performance.
Option A is incorrect.
Consistency across DynamoDB does reach within 1 second.
But it is the DynamoDB's read model rather than the lag that causes stale data to appear.
Option B is CORRECT.
The default read model supported by DynamoDB is an “Eventually Consistent” one as described above.
Option C is incorrect.
DynamoDB supports strongly consistent reads but by default it uses eventually consistent reads.
Option D is incorrect because of the reasons discussed above.
Reference:
https://youtu.be/SqMevk3n3EQ https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.htmlThe possible reason for John still seeing his Last Name as "Abraham" after an update could be due to the eventual consistency model used by DynamoDB, which is the default behavior for read operations. In other words, the data may not have been propagated to all copies of the data in DynamoDB at the time of John's read operation, resulting in a stale read.
DynamoDB is a NoSQL database service offered by AWS that provides fast and flexible document and key-value store capabilities. To achieve high availability and durability, DynamoDB replicates data across multiple servers within an AWS Region or across multiple regions.
DynamoDB offers two types of consistency models for read operations: eventual consistency and strong consistency. By default, DynamoDB uses eventual consistency, which means that the data read may not reflect the most recent write operation for a short period. This is because the data is replicated across multiple servers asynchronously, and it takes time to propagate the changes to all copies of the data. In other words, eventual consistency sacrifices consistency in favor of availability and performance.
On the other hand, strong consistency ensures that the data read reflects the most recent write operation. However, strong consistency may impact availability and performance, as it requires additional communication between the servers to ensure that the data is consistent across all copies.
In the given scenario, if the application requires strong consistency, the read operation should be configured to use strongly consistent reads, which are available as an option in DynamoDB. If the application can tolerate eventual consistency, the application should be designed to handle stale reads.
To summarize, the possible reason for John still seeing his Last Name as "Abraham" after an update is due to the eventual consistency model used by DynamoDB, which is the default behavior for read operations. The correct answer to the question is B, which states that by default, DynamoDB reads are eventually consistent.
