Thread by @ksshams

#DynamoDB strongly consistent reads are magical, but not for the reason most of us think.

SC reads have higher latencies, lower availability, and cost more - but worth it if you use them for the right reasons.

🧵👇explains what they are & how to unlock their real power!

0\ Primer: Doug Terry does a phenomenal job explaining the various consistency models through an illustrative exercise:
microsoft.com/en-us/research…

Read this first to become a consistency ninja!

1\ The most common mistake I see with DynamoDB SC reads is assuming it’s fresher than it is. Suppose you want to increment a counter: an SC Read tells you X=2 - you *cannot* set X=3 because another thread may have already changed it in the meantime. Use Conditional Puts instead!

2\ A strongly consistent (SC) read implies the data is at least as fresh as when you issued the request - and NOT when you receive the response or act on it. A lot can happen while the response is in transit.

3\ A good framework to think about this is to assume that your request made it to DynamoDB in zero time - but it took an extra minute to make it back to you. A lot can happen in a minute - but a lot can happen in 1ms too :).

4\ The SC reads are routed to the leader of a partition, which will give you the latest data while it is processing your request. However, all that can change as it serializes your response and some other request updates the underlying data.

5\ The second most common mistake is to assume EC reads are staler than they really are. This leads to superfluous use of an SC when you could have used an EC read. 📣 EC reads in DynamoDB are almost as fresh as SC reads. 👇

6\ DynamoDB leader only acks a write if it AND a 1 follower has gotten the update. So, there is a 66% chance that an SC request lands on the same node as an EC request. Lagging replicas usually catch up within milliseconds, which makes this very hard to observe.

7\ SC read before Conditional Puts is usually overkill too. This has an inconsequential impact on the likelihood of your Conditional Put succeeding. If it gets you more recent data than EC, chances are there is too much going on in your system to be using OCC.

8\ The third most common mistake with DynamoDB SC reads is to overlook their downsides! SC reads have higher latencies, lower availability, and cost double!

9\ DynamoDB SC reads have lower availability because they read from the leader. If the leader is unavailable/getting re-elected, you’ll get an error. They can also only support 1/3rd the throughput - so you are more likely to cause a brown out or throttle on your table with them.

10\ DynamoDB SC reads are slower than EC reads because the request router may have stale data on who the leader really is. “If read requests do not reach the Leader node on the first attempt, then strongly consistent reads may experience a higher latency.”

11\ So why would you use SC reads in DynamoDB? Monotonic reads! 👇

12\ Dynamodb strongly consistent reads ensure that you can only go forward in time (monotonic reads). Consider 2 serial EC reads.The first one goes to the leader - but the second one goes to a follower that’s behind. Time travel backwards can be bad! and creates odd behaviors👇

13\ If a shopping cart goes backwards in time, a customer may not see the item that they just added - OR - they may see an item that they just took out of the cart.

Similarly, my bank balance, chats, or scoreboards for a soccer game should only go forward in time.

14\ The lack of time travel makes SC reads magical. You can be doing an SC read at a to render a dashboard from 100 different lambdas. My screen will never go backwards in time despite the concurrency or lack of stickiness.

15\ You put the same workflow with EC reads - and once in a while, you will see a stale value. This could lead to confusion or erode consumer trust.

Fin.
SC reads are magical if you are using them for the right reasons. Understanding how they work makes you appreciate them even more. Thx @alexbdebrie @pj_naylor @akshatvig @somu_peri for helping w/ this 🧵. Stay tuned for a 🧵 on how to reason about DynamoDB transactions!