Hey, everyone, and welcome back.
Now, in today's video, we are going to discuss about the overall consistency model specifically related
to the Dynamo DB.
Now, since Dynamo DB is a managed service in Dynamo DB, all of your data is stored on the SSD and
is automatically replicated across multiple availability zones in the Amazon region, which in turn
provides the built in high availability and data durability.
For example, you have a Dynamo DB table over here and there are three availability zones in the region.
Now if you go ahead and add some data to the Dynamo DB behind the scenes, this data would be replicated
across all of the availability zones.
Now, in case if one of the availability zone goes down, the Dynamo DB can still retrieve the data
from the other availability zones over here.
Now, one important thing to remember at this stage is associated with the consistency timeline.
So when your application writes the data to the Dynamo DB table and it receives a 200 okay response,
the right has occurred and is durable behind the scenes.
Now also note that this data that is written will eventually be consistent across all the storage location,
usually within one second or less.
So this is very similar to what we are discussing when you write some data to the Dynamo DB since it
is replicated and added across multiple availability zones, this data will eventually be consistent
across all the storage locations.
It's not that in the same duration it can be millisecond.
The data would be consistent across all the availability zone.
It can happen that at this stage you'll see that this new data is consistent across the two availability
zone, but it is not added in the availability zone three or you can say it is not updated in the availability
zone three as of this duration.
All right.
So this eventual consistency is usually within one second or less.
Now comes the important concept of eventual consistency read.
So when you read the data from Dynamo DB table, the response might not reflect the result of the recently
completed right operation, and this response might include some stale data or might include some older
data.
And if you repeat your read request after a short amount of time, the response should return the latest
data over here.
So this is the basic of eventual consistent read.
Now you also have something called as the strong consistent read.
Now when you request for a strong consistent read, Dynamo DB returns a response with the most up to
date data reflecting the updates from all the prior write operations that were successful.
So in the Dynamo DB, let's quickly create a new table here.
We'll use a customized setting and in the capacity calculator here you have under the read consistency,
you have eventually consistent, strong, consistent as well as transactional.
For today's video, we are more focused towards eventually consistent and strong consistency.
This is what we are looking into now as we discussing eventually consistent can result in some stale
data based on some very recent rate operation that had occurred in the Dynamo.
DB So to overcome this in case if you do not need stale data at all, there are a lot of applications
where you cannot afford to have a stale data.
So in such cases you can go for a strong consistency.
Now in this case, a strong consistency lead might not be available if there is a network delay or there
is an outage.
In this case, the Dynamo DB will immediately return you with a 500 error.
Second is strong consistency.
It may have a higher latency than that of the eventually consistent right.
And third important point is strong consistent read uses more throughput capacity than the eventual
consistent read.
Now at a high level overview, one thing that you need to note is that by default, eventually consistent
read is generally used.
You can also select the strong consistent read, but not that it will come with an additional cost.
For example, let's go ahead and modify the set of values here for strong consistent read.
It is costing $25 per month.
If you select eventually consistent read, it is costing $24 per month.
So a few important things to note as we're discussing the Dynamo DB uses the eventually consistent reads
unless you go ahead and specify otherwise.
So various operations like read operation related to get item, query and scan provides a consistent
read parameter.
And this parameter is something that you can set to specify the strong consistent rate.
For example, when you use the Dynamo DB SEAL Command forget item, you can specify a hyphen, hyphen,
consistent reader, warrior, and this will go ahead and use the strong consistent read for fitting
this specific.
Item, so let's quickly look into it.
So in the dynamo typically of gate item, which basically fetches item from the Dynamo DB table, you
have an option of consistent read and no consistent rate.
Let's go a bit down.
So if you look into the description here, it states determines the read consistency model.
If it is set to true, then the operation uses strong consistent read.
Otherwise the operation uses the eventual consistent read.
So this is how you can specify as part of your application as well, in case if you'd like.
Great.
So that's the high level overview about the consistency model.
And with this will conclude today's video.