[evanweaver]

Dynamo strongly consistent transactions are still limited to a single region, and are eventually consistent outside of that region. For example, in Dynamo, it is not possible to enforce uniqueness via multi-region strongly consistent transactions. Fauna can do this.

The Dynamo transactions do increase latency, but not to the same degree as Fauna. However, they are not achieving the same level of transactional correctness either, or really any correctness at all in a multi-region context.

[confuser]

I struggle to think of a scenario where cross-region transactions would be useful. Why not just pick a primary region where transactions will be carried out for a given piece of data if consistency guarantees are needed?

[redis_mlc]

I'm a DBA, and I agree. Cross-region transactions rarely make sense because if one region is not reachable (down, network-partitioned for more than 1 minute), then you can't do writes to any region. Think about it. :)

I guess if your partition time interval was known to be very short, like a flaky ISDN link, it could make sense for some use cases using retries, but then you should just get a better link.

CockroachDB discusses a multi-city vehicle sharing use case where multi-region transactions could be worth consideration, but I'm skeptical:

https://www.cockroachlabs.com/docs/stable/multi-region-use-c...

(Developers and students get all excited about distributed systems, CAP, etc. but as a DBA, network partitions are largely not solvable from both technical and business standpoints. The solutions that do work include using vector clocks, or investing in a very reliable network, which is what Google is doing with dedicated fiber.)

[evanweaver]

You can indeed perform writes in other regions; this is the entire point of Calvin, Spanner, and other modern distributed transaction algorithms: maintaining consistency and maximizing availability in the face of partitions. Your perspective is about a decade out of date.

[k__]

Yes, I know.

I was just interested if a ConsistentRead would change the latency.

[evanweaver]

It has to to acquire and release locks, so yes.

[ec109685]

Are you sure about that? DynamoDB is paxos based, so that seems unnecessary.

Given data is always replicated to at least 2 of 3 storage nodes before ACK’ing, you can always just read from 2 different replicas and be sure you have the latest data.

[evanweaver]

Oh, I thought you were referring to the multi-key consistent transactions, not single key strong consistency mode. I think you are correct.