Hey there Saten,
As opposed to some other RDBMS systems which do hot-hot topologies by copying data between nodes potentially after acknowledging a transaction, Cockroach requires raft consensus between all nodes which contain the ranges of data affected before acknowledging the write to the client, so there is no opportunity for “replication lag” to come into play.
This means that by the time your client completes it’s write on node A, the write has already been preformed and committed on a quorum of other nodes which contain replicas of that range of data. Since a quorum is required for all writes, even if the data from the first write is only replicated to a subset of the range replicas (say 2 out of 3), if you were to try a conflicting write operation on the 3rd node missing the prior writes, the transaction would be aborted once the nodes establish raft consensus and detect the conflict.
If there are connection issues or latency between your nodes, this may surface as an increased transaction latency, or a hung or aborted transaction, depending on the nature of the problem.
Some more info about the consistency guarantees can be found in the docs.