DynamoDB Eventually Consistent vs. Strongly Consistent Reads

Read Consistency

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

Although we successfully avoid some setbacks and failures with this approach, there is an unavoidable fact that we should admit with this approach. When a user performs a mutation, they must update it on all physical nodes. Therefore, data inconsistency is possible when reading data from a node that has not yet been updated. We call it 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 look at the account balance or the transaction effect. He does not expect delays, leading to a bad user experience. Data speed reading, therefore, is one aspect of reading consistency.

Another aspect of reading consistency is that if you are performing a workflow that affects the result of the first step to 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 fetching data, we need to wait and make sure 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-up or update in a post-reading process of the same value.

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

• Eventually consistent model
• Strongly consistent model

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

Eventual Consistency vs. Strong Consistency in DynamoDB

Eventual Consistency

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

Strong Consistency

While the DynamoDB table supports strongly consistent reading, it results after all mutations have been fully activated. Therefore, this model will guarantee the return of the most updated data. The process behind this behavior is by locking down the physical nodes as they update.

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. Of course, you should do this while doing the reading operations.

The following code demonstrates how we can enable strongly consistent, GetItem reading operation by setting 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 return JSON object is the latest value that meets the given conditions.

Pros and Cons

The eventual consistency model always returns data with low latency. Also, this model prioritizes availability over consistency. An eventual consistent read model is suitable to perform independent tasks from each and 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. Again the implementation of the application will be complex with eventual consistency since it makes the debugging process hard.

Strong consistency gives the guarantee as it will return the most updated data. The system will be more accurate with the strongly consistent model but there drawbacks with this model. 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). Having higher latency than eventually consistent reads, not supported on global secondary indexes, using more throughput capacity than eventually consistent reads are other drawbacks for strong consistency read models.

When to Use Which

Case Study 01:

An enterprise solution application may have a large number of entities. Some entities might be working together, but many acts as separate units. For example, let's take two entities as CustomerOrder and FixAssest. While user "A" performs some mutation on CustomerOrder, user "B" can read data from the FixAssest entity. If there are many results in that query, then the user "B" 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 fast-fetching than the strongly consistent reading model.

Case Study 02:

When we think about an online retail application, many users are involved simultaneously. The stores' stock has to manage 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 giving the wrong 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 readings, but it should be defined at the table creation stage.

Is DynamoDB eventually consistent?

The eventual consistency option is the default read-consistent model for Amazon DynamoDB.

What is the default consistency model for DynamoDB?

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

Which DynamoDB operation is the most read-intensive?

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 for the partition key.

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