3.4: Consistency

Consistency refers to whether a particular read operation receives all write operations that have occurred prior to the read.

As we just read in the previous section, DynamoDB splits up, or "shards", its data by splitting it across multiple partitions. This allows DynamoDB to horizontally scale by adding more storage nodes.

When you write data to DynamoDB, there is a request router that will authenticate your request to ensure you have access to write to the table. If so, it will hash the partition key of your item and send that key to the proper primary node for that item.

The primary node for a partition holds the canonical, correct data for the items in that node. When a write request comes in, the primary node will commit the write and commit the write to one of two secondary nodes for the partition. This ensures the write is saved in the event of a loss of a single node. After the primary node responds to the client to indicate that the write was successful, it then asynchronously replicates the write to a third storage node.

Thus, there are three nodes—one primary and two secondary—for each partition. These secondary nodes serve a few purposes. First, they provide fault-tolerance in case the primary node goes down. Secondly, these secondary nodes can serve read requests to alleviate pressure on the primary node.

However, notice that there is a potential issue here. Because writes are asynchronously replicated from the primary to secondary nodes, the secondary might be a little behind the primary node. And because you can read from the secondary nodes, it’s possible you could read a value from a secondary node that does not reflect the latest value written to the primary.

With that in mind, let’s look at the two consistency options available with DynamoDB:

- Strong consistency: any item you read from DynamoDB will reflect all writes that occurred prior to the read being executed.

- Eventual consistency: with eventual consistency, it’s possible the item(s) you read will not reflect all prior writes.

Finally, there are two times you need to think about consistency with DynamoDB.

First, whenever you are reading data from your base table, you can choose your consistency level. By default, DynamoDB will make an eventually-consistent read. However, you can opt into a strongly-consistent read by passing ConsistentRead=True in your API call. An eventually-consistent read consumes half the write capacity of a strongly-consistent read.

Second, you should think about consistency when choosing your secondary index type. A local secondary index will allow you to make strongly-consistent reads against it, just like the underlying table. However, a global secondary index will only allow you to make eventually-consistent reads.