Chronological timestamps of transactions in a financial system

I have a high-volume, concurrent application with business transactions updating several tables via a series of DB calls over a network. While the DB ensures ACIDty, the transaction timestamps are not guaranteed to be chronological out of the box. For example, transaction A can start **before** transaction B but commit **after** it. Our business requires that financial ledgers follow strict chronological order, in this case, transaction A's timestamp(6) should be after transaction B, because transaction A finished (committed) last. Naively, one could set the transaction time at the end of a transaction, a final step before the commit, however due to variability of network latency this is obviously not guaranteed to work. Commits can take unpredictably long. **Question: Is serialization of transactions at the application/system level, the only way to deal with this?** **Proposal 1:** I can run transactions for different (business) accounts concurrently, but within a single business account I might have to serialize globally. Unfortunately some accounts are large, with transaction volumes in 4000/min rates, so even per-account serialization will add significant delays. If there is a better solution to this please let me know. **Proposal 2:** Every app-node generates a unique ID (GUID) prior to starting the transaction. This represents a transaction ID which does not carry time but is accompanied with every modification as part of the transaction. As the last step of our transaction, we insert a row into a table like below, then commit: INSERT INTO transaction_sequence(transaction_guid) value ("GUID"); Table transaction_sequence: transaction_guid varbinary(16) NOT NULL, transaction_time datetime(6) NULL Above, the row that we insert as the last step of a transaction won't have a timestamp either. Later, there is a separate backend process that backfills the **transaction_time** with timestamps* according to their relative order of commits *as determined from the binary-log of the MariaDB/MySQL system files*. This solution is database engine specific and therefore not ideal but back-filling of timestamps will not inhibit concurrency in any way. **Proposal 3:** Use MariaDB-specific **transaction-precise history** extension on the **transaction_sequence** table, documented here . This extension will (hopefully) eliminate my need to process binary-log files although it remains DB engine specific. *) The timestamps are interpolated with approximate transaction completion times and be guaranteed chronological. My challenge is described by this paper: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/temporaltime.pdf