delaying writes by a factor longer than the max clock skew of the cluster is a pretty common strategy. It is what Google Spanner does.

Right but it's not magic as you cannot predict networking delays.

The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.

What if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

Thanks for the link, not much familiar with CockroachDB but I worked on a similar system that wanted to provide strong consistency when reading from many databases, some of which where Spanner but not all of them.

Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads for writes.

What I missed the most from Spanner compared to the system above is that its tricky to do client-side transaction chaining where there are many clients and the order is important.

If you put a atomic clock like OCP-TAP Time Card with GNSS receiver in every server and use precision time protocol to sync them you should be able to synchronize quite a few servers to less than 100 nanoseconds.