"Strong Consistency" vs. "Read-after-write Consistency"

Question

Why does AWS says "strong consistency" in DynamoDB and "read-after-write consistency" for S3? Do both of them mean the same thing?

Answer 1

The two terms essentially mean the same thing, in the sense that read-after-write is one type of strong consistency.

The noteworthy difference is that DynamoDB's strong consistency includes read-after-update and read-after-delete, as well as read-after-write. S3 only offers read-after-write... so we could say read-after-write is a subset of strong consistency.

In S3, everything is eventually consistent with one exception: if you create an object and you have not previously tried to fetch that object (such as to check whether the object already existed before creating it) then fetching that object after creating it will always return the object you created. That's the read-after-write consistency in S3, and it's always available in the circumstance described -- you don't have to ask S3 for a strongly-consistent read-after-write on a new object, because it's always provided.

Any other operation in S3 does not have that consistency guarantee. Examples:

• fetch a nonexistent object, get a 404, then create it, then immediately try to fetch it again. You might get it, but you might continue to get 404 for a short time.
• create an object in S3, then fetch a listing of objects in the bucket. The new object may not immediately appear in the list.
• download an object, delete it, then try downloading it again. You might succeed for a short time. You will eventually get a 404.
• download an object, then overwrite it. Download it again. You might get the new object, or you may get the old one for a short time. You will not get a corrupt or partial object, but you may get the old or the new.

All of these are aspects of the S3 Consistency Model which are the result of optimizations for performance.

DynamoDB is also optimized for performance, and as a result, it defaults to eventual (not strong) consistency, for the same reasons... but you can specify strongly-consistent reads in DynamoDB if you need them. These come with caveats:

• 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).

• Strongly consistent reads may have higher latency than eventually consistent reads.

• Strongly consistent reads are not supported on global secondary indexes.

• Strongly consistent reads use more throughput capacity than eventually consistent reads

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html

Answer 2

For those seeing this post in December 2020 and later, an update – AWS S3 now delivers strong consistency automatically for GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata. Bucket configurations have an eventual consistency model.