Strongly vs Eventual Consistency Modes in DynamoDB

DynamoDB is a fully managed serverless, NoSQL database offered by AWS. It is particularly popular due to its single-digit millisecond performance at any scale(if used properly!).

\ As with any other database technology, data consistency is important, however, how each database achieves consistency varies. In DynamoDB, there are two consistency modes. It’s important to understand these consistency modes, then decide and use whichever fits your use case, otherwise, you might end up with weird read/write behaviors that can lead to bugs in your software.

Eventual Consistent Mode

In eventual consistent mode, the data read from the database is not guaranteed to reflect the latest state of the data in the database. This means the result returned in your read requests might not always reflect recently completed writes. This might not be a big deal for your application given that DynamoDB should reach consistency in a few seconds, however, it is important to know that there’s no guarantee of exactly how long this will take. This is the default in DynmaoDB, i.e. unless explicitly specified, all database reads will happen in eventual consistent mode.

\ Example eventual consistent query using@aws-sdk/client-dynamodb SDK:

\

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb'); const client = new DynamoDBClient({}); async function getItem() { try { const command = new GetItemCommand({ TableName: 'YourTableName', Key: { // Define item primary key (optional sort key) }, }) const data = await client.send(command); console.log('Item retrieved:', data.Item); } catch (error) { console.error('Error retrieving item:', error); } } getItem();

\

Strongly Consistent Mode

In strongly consistent mode, the data read from the database is guaranteed to reflect the latest state of the data in the database. This means the result returned in your read request will reflect the most recently completed writes. To perform a strongly consistent read, you need to explicitly specify in your read request.

\ Example strongly consistent query using@aws-sdk/client-dynamodb SDK:

\

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb'); const client = new DynamoDBClient({}); async function getItem() { try { const command = new GetItemCommand({ ConsistentRead: true, // This parameter enables Strongly Consistent mode TableName: 'YourTableName', Key: { // Define item primary key (optional sort key) }, }) const data = await client.send(command); console.log('Item retrieved:', data.Item); } catch (error) { console.error('Error retrieving item:', error); } } getItem();

\

Which one do I use?

Ultimately it depends on your use case. Some applications require strongly consistent reads because there’s a high write/read frequency/dependency, however, for some applications, a few seconds delay before reaching latency across the database is acceptable.

\ One important factor to consider when deciding which consistency mode to use is cost :moneymouthface:. DynamoDB has two pricing options, On-Demand, and Provisioned Capacity, you can read more about the different options here.

\ For the On-Demand pricing option; a strongly consistent read of up to 4kb of data requires one RRU(Read Request Unit), while an eventual consistent read of the same data size requires a half RRU.

\ For the Provisiond Capacity pricing option; a strongly consistent read of up to 4kb of data requires one RCU(Read Capacity Unit), while an eventual consistent read of the same data size requires a half RCU.

\ In summary, a strongly consistent read is about twice(x2) the cost of an eventual consistent read. It’s probably worth taking your time to think hard if you need strongly consistent reads or if an eventual consistent read can somehow fit your use case.

\ What are your thoughts about Eventual & Strongly consistent modes in DynamoDB? Have you had to make a choice to choose Strongly over Eventual Consistent mode? Please share in the comments section.

\ \