I'm reading through an article on why SQL databases are hard to scale and problems with ACID.
Here's the link to the short article: Link
Today's solution is usually post-write replication, where each transaction is executed first at some primary replica, and updates are propagated to other replicas after the fact. Basic master-slave/log-shipping replication is the simplest example of post-write replication, although other schemes which first execute each transaction at one of multiple possible masters fall under this category. In addition to the possibility of stale reads at slave replicas, these systems suffer a fundamental latency-durability-consistency tradeoff: either a primary replica waits to commit each transaction until receiving acknowledgement of sufficient replication, or it commits upon completing the transaction. In the latter case, either in-flight transactions are lost upon failure of the primary replica, threatening durability, or they are retrieved only after the failed node has recovered, while transactions executed on other replicas in the meantime threaten consistency in the event of a failure.
I'm assuming that by the former statement, it is pointing to the semi-synchronous replication and by latter it points to the asynchronous replication such that a commit is said to be successful as soon as the transaction is committed on the primary replica.
However, I didn't quite get what does it mean by losing the transaction upon failure and how are in-flight transactions lost in synchronous replication and not the semi-synchronous case? Can anyone help to explain?
Isn't a transaction saved to disk before it's being executed?