DynamoDB Eventually Consistent vs. Strongly Consistent Reads

Read Consistency

With their storage solutions, especially DynamoDB, Amazon Web Services (AWS) provides high durability and availability. They use read replicas to achieve this feature and promise enhanced data read performance. AWS deploys these multiple physical nodes in different regions. You can find out more about it here.

Although this approach successfully avoids some setbacks and failures, there is an unavoidable fact that we should admit. When a user performs a mutation, it must be updated on all physical nodes. Therefore, data inconsistency is possible when reading data from a node that has not yet been updated. This is known as the return of stale data. How consistent your readings are depends on how fast the database copies are updated, and usually, these nodes update in a matter of seconds or less.

Why is Read Consistency Important?

Read consistency is easier to explain with real-world events. For example, Internet banking applications are widely used for banking transactions in the modern world. When a customer makes a transaction, the customer does not have the patience to wait to see the account balance or the transaction effect. They do not expect delays, leading to a bad user experience. Data speed reading, therefore, is one aspect of read consistency.

Another aspect of read consistency is that if you are performing a workflow where the result of the first step affects the second step, you should wait until the previous step is fully executed before moving on to the next transaction. In this case, instead of focusing on speed, we need to ensure that the data on all read replicas are updated.

Consistency Models in DynamoDB

A database consistency model defines how and when it will reflect a successful write or update in a subsequent read process of the same value.

Amazon DynamoDB introduces two models for reading requests through the application. These are:

• Eventually consistent model
• Strongly consistent model

The eventual consistency model is the default on Amazon DynamoDB, and it maximizes read throughput.

Eventual Consistency vs. Strong Consistency in DynamoDB

Eventual Consistency

When the DynamoDB table supports eventual consistency reads, the response may not reflect the results of recently completed mutations. Instead, the result may include some stale data. Stale data refers to data with an older version.

Strong Consistency

When the DynamoDB table supports strongly consistent reads, the results reflect all mutations that have been fully propagated. Therefore, this model guarantees the return of the most updated data. The process behind this behavior involves ensuring that all physical nodes are updated before returning the data.

Read operations such as GetItem, Query and Scan provide a ConsistentRead parameter. When the user sets this parameter to True, DynamoDB uses strongly consistent reads. This should be done during the read operations.

The following code demonstrates how we can enable strongly consistent GetItem read operation by setting the ConsistentRead parameter to true.

const AWS = require("aws-sdk");
AWS.config.update({ region: "us-east-2" });
var ddb = new AWS.DynamoDB({ apiVersion: "2012-08-10" });

var params = {
  ConsistentRead: true,
  Key: {
    "EngineNo":{
      S: "541Wr754"  
    } ,
    "Model": {
      S: "RANGE ROVER SPORT",
    }
  },
  TableName: "Vehicle",
};
ddb.getItem(params, function (err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else console.log(data); // successful response
});
const AWS = require("aws-sdk");
AWS.config.update({ region: "us-east-2" });
var ddb = new AWS.DynamoDB({ apiVersion: "2012-08-10" });

var params = {
  ConsistentRead: true,
  Key: {
    "EngineNo":{
      S: "541Wr754"  
    } ,
    "Model": {
      S: "RANGE ROVER SPORT",
    }
  },
  TableName: "Vehicle",
};
ddb.getItem(params, function (err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else console.log(data); // successful response
});

This will return a JSON object with corresponding values to the vehicle table created in DynamoDB. The returned JSON object is the latest value that meets the given conditions.

Pros and Cons

The eventual consistency model always returns data with low latency. This model prioritizes availability over consistency. An eventually consistent read model is suitable for performing independent tasks, which will impact the scalability, performance, and availability of systems at scale. The downside of the eventual consistency model is that it may return stale data. Additionally, the implementation of the application can be complex with eventual consistency since it makes the debugging process harder.

Strong consistency guarantees the return of the most updated data. The system will be more accurate with the strongly consistent model, but there are drawbacks. For example, some operations may fail if an insufficient number of object replicas are available. Also, a strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500). Other drawbacks include higher latency than eventually consistent reads, not being supported on global secondary indexes, and using more throughput capacity than eventually consistent reads.

When to Use Which

Case Study 01:

An enterprise solution application may have a large number of entities. Some entities might work together, but many act as separate units. For example, let's take two entities as CustomerOrder and FixedAsset. While user "A" performs some mutation on CustomerOrder, user "B" can read data from the FixedAsset entity. If there are many results in that query, then user "B"'s experience may not be affected by the operation of user "A." So, in this case, eventual consistency reading will be the best solution. Also, it is faster than the strongly consistent reading model.

Case Study 02:

When we think about an online retail application, many users are involved simultaneously. The store's stock has to be managed dynamically, and the user should be able to see the actual available products with better accuracy. If we use eventual consistency reading to show the inventory details, there is a high risk of providing incorrect information. To avoid bad user experiences, we should go with strongly consistent reading, which ensures that clients will never see out-of-date values.

FAQ

Is DynamoDB strongly consistent?

Yes, DynamoDB supports strongly consistent reads, but it should be specified at the time of the read operation, not at the table creation stage.

Is DynamoDB eventually consistent?

Yes, the eventual consistency option is the default read consistency model for Amazon DynamoDB.

What is the default consistency model for DynamoDB?

DynamoDB uses eventual consistency reads as the default unless you specify otherwise. If the user wants to use strongly consistent reads, the user must select this when performing the read operation.

Which DynamoDB operation is the most read-intensive?

The Scan operation is more read-intensive than other operations in DynamoDB. In the Query operation, the user needs to pass the partition key, and it will return the overview of that record. This record is specific only to the partition key.

Scan can pass multiple parameters with various conditions and help us to get more specific data or be more intensive for reads.