The question here is really "When do you need distributed transactions"? One of misuses is when one cannot achieve enough performance on a single node. E.g., on

The question here is really "When do you need distributed transactions"? One of misuses is when one cannot achieve enough performance on a single node. E.g., one builds a system serving 1000 REST requests per second (RPS), achieving 2 seconds latency per request, having a DB as a bottleneck. To be honest, I've seen real software built giving 23 sec latency per only 50 RPS. Does it mean there is a need to scale it out or simply that a chosen DB is a problem? The cases I've seen through my practice are mostly on the latter. Simply choose the most suitable solution, not the most hyped one. A mistake would be to sacrifise transactions via using some "general NoSQL database". Today, for real, you can have a single node capable of millions RPS on real-world scenarios with ACID transactions of arbitrary complexity, choosing solution like http://starcounter.io/ http://starcounter.io/. Please, please don't just take yet another no-transactions DB, which is no-transactions even on a single machine, having 4 db nodes on 4 cores completely separate as if they've been 4 different machine. Then you observe bad performance and start to scale things up, paying more and more for the cloud. Not the best idea to spend time and money. And, if you DO really need distributed transactions, then it mostly means they'd be driven by a logic of your subject domain. E.g., you might have one department in Sweden, one in the USA, then you need to manage distributed accounts in the right way, where "right" is up to your banking policy. However, if you need to scale reads, there is just no problem of doing so within "no-distributed-ACID" solution. The same time, if you need to scale writes, doing distributed transactions isn't a good idea either, as you've seen from the topic starter article. So, right tool for the right job. Outside of the brackets I keep a topic of fighting with latency via distributed transactions. I mean those things around caching, CDN and async replication. Distributed transaction isn't a remedy there at all, since it doesn't patch speed of light by any means.