Consistency

Each node keeps a counter per participant. Comparing vectors reveals a causal edge or a true concurrent write, which decides whether to merge or to ask. One timestamp is not enough A single timestamp cannot order concurrent events, because a clock is not a cause, so two nodes that each wrote something at the same label may still disagree about which came first. Vector clocks solve that by giving every participant its own counter: a process bumps its own slot whenever it does something, and merges the sender’s vector into its own whenever it receives a message. The result is a vector that grows as events happen, and comparing two vectors tells you whether one event provably preceded the other, or whether neither did. ...

Choose an isolation level from the invariant an operation must preserve. A stable snapshot is useful, but two transactions can each make a locally reasonable decision that becomes invalid when both commit. PostgreSQL Repeatable Read prevents changes to a transaction’s reading snapshot, yet permits some serialization anomalies. Serializable adds detection that rejects combinations of concurrent work inconsistent with any serial execution, requiring the application to handle retries. ...