Epoch-Based Optimistic Concurrency Control

Raising the unit of coordination from the transaction to the epoch makes wide-area round-trip cost scale with the number of epochs rather than the number of transactions.

The wide-area round trip inside the commit path

A multi-leader database with leaders in several regions raises availability by accepting writes anywhere. In exchange it has to preserve ACID across every replica, which requires global concurrency control. Those synchronization protocols usually need multiple rounds of communication, and each round adds wide-area network (WAN) latency to the commit path.

Existing answers differ in when they pay for coordination.

All three move the moment of coordination around, but a round trip stays somewhere in the commit path. Minerva, proposed by Mao et al. (2026, arXiv:2602.21566), instead pulls coordination out of the commit path entirely.

Batching commit and replication into epochs

Optimistic concurrency control (OCC) runs a transaction without locks and then, just before commit, validates whether the data it read changed in the meantime. If it changed, the transaction aborts and retries. In a geo-distributed setting the question becomes where that validation runs. If validation has to inspect the state of a remote region, a round trip re-enters the commit path.

Minerva raises the unit of validation from the transaction to the epoch. Time is cut into fixed-length intervals, set to 15ms in the paper, and each replica executes and commits transactions locally without delay. The write sets of committed transactions accumulate per epoch and are shipped to the other regions. Shipping triggers on whichever comes first, a 4MB size threshold or a 5ms timeout, so data propagation runs on a separate clock from commit.

The effect is a change in what the coordination count scales with. Paying a round trip per commit makes coordination cost proportional to the number of transactions, while exchanging once per epoch makes it proportional to the number of epochs. Under a load that commits thousands of transactions in 15ms, that gap shows up directly as a throughput gap.

The price is that conflicts surface late. Two regions can each update the same record and each commit it. That fact only becomes visible when write sets are exchanged at the epoch boundary, so conflicts between already-committed transactions have to be handled after the fact.

Deterministic re-execution instead of abort

Classic OCC would abort the conflicting transaction at this point. Minerva re-executes it instead, running five stages at epoch commit time.

A transaction chain is a group of transactions linked by dependencies within the same batch. Judgment happens per chain rather than per transaction, so when an earlier transaction is invalidated, the transactions that follow it become invalidation candidates as well.

The staleness check asks whether an item in the chain's read set carries an epoch id older than the current one, or whether a preceding transaction aborted. The criterion is the epoch id, not a timestamp. No physical clocks are compared, so Network Time Protocol (NTP) synchronization error never enters the decision.

The conflict graph places chains as vertices and draws an edge for each write-write or read-write conflict between a pair of chains. A vertex weight is the number of transactions in that chain. Solving for the maximum weight independent set (MWIS) yields the subset that keeps the largest number of transactions committed without conflicts among them. At low conflict rates the exact solution comes from integer linear programming (ILP), and at high conflict rates a greedy approximation is used.

Chains that fall outside the independent set are re-executed. The ordering key is the transaction id (tid) plus the static priority of the source replica. Every replica sorts by the same rule, so all of them reach the same order without a round of consensus. Re-execution then runs under Calvin-style deterministic locking, and since the read and write sets are already known at that point, no deadlock arises.

The difference from Calvin is the scope over which determinism applies. Calvin needs the read and write sets of every transaction before execution. Minerva executes first and narrows deterministic re-execution to the transactions that were confirmed to conflict.

Cost that moves with the conflict rate

Table 1 of the paper breaks epoch commit time into stages under saturation in a 500ms latency environment.

The total is roughly the same in both cases, around 32.5ms, but the cost inside it moves. When conflicts are rare, the staleness check and graph construction dominate at 6.84ms and 5.62ms respectively, and re-execution stays under 1ms. When conflicts are frequent, re-execution takes 17.53ms, more than half of the total.

The MWIS optimization is a safeguard against unnecessary aborts while conflicts are rare. Once conflicts become common, the system shifts its weight from optimization toward absorbing the cost of re-execution.

How much re-execution occurs is set by the access distribution of the workload. In the YCSB-A experiment with a Zipfian distribution, shown in figure 10 of the paper, the re-execution ratio grows with the coefficient.

Past a coefficient of 1.2, a separate mode that bypasses the MWIS computation turns on. The re-execution ratio stops climbing near 35% because that mode caps it.

Which workloads it wins on

The paper compares against three groups. They are geo-replicated multi-leader databases (GeoGauss, Ocean Vista, CockroachDB), epoch-based systems (COCO), and deterministic databases (CalvinDB). Throughput measured with TPC-C separates further as round-trip time (RTT) grows.

The unit is transactions per second, read approximately off figure 6 of the paper. At 0ms RTT there is little separation from CalvinDB and GeoGauss, but at 200ms the gap reaches roughly 3.8x over CalvinDB. The gain from epoch batching scales with round-trip latency, so a deployment where inter-region RTT sits at a few milliseconds has little reason to adopt it.

Scalability in the number of replicas points the same way. With 15 replicas Minerva recorded about 12,000 transactions per second, 1.5x CalvinDB at about 8,000 and 4x GeoGauss, COCO, and CockroachDB at about 3,000. Latency barely moved when replicas grew from 3 to 15, going from 17ms to 18ms on TPC-C.

Two conditions summarize where the design applies. Inter-region RTT has to be large enough that the per-commit round trip dominates, and the conflict rate has to stay within what re-execution can absorb. Either way commits are finalized at epoch boundaries, so the design does not fit workloads where the response time of an individual transaction comes first.

The same shape of problem exists outside the transaction layer. Toss Securities ran into a bidirectional mirroring loop while configuring Kafka as Active-Active for data center redundancy. A message replicated from DC1 to DC2 was treated by DC2 as new data and sent back to DC1, and the team broke the loop by tagging the source DC in the message header.

Both cases share the same move. Rather than coordinating with a remote party on every request, they embed metadata that identifies provenance in each event or transaction and decide locally. The epoch id in Minerva is likewise a tag marking which point in time the data belongs to. The difference is the guarantee. Eventual consistency suffices at the messaging layer, while Minerva carries the guarantee all the way to serializability through re-execution.

Remaining constraints

MWIS is NP-hard in general. On extremely high-contention workloads, where the conflict graph grows dense, even computing an approximation carries a cost that is hard to ignore. The paper routes around this with the high-contention mode. But the evidence for the switch threshold near a Zipfian coefficient of 1.2 is limited to that experimental distribution. Whether the same threshold holds under other access distributions has not been verified.

The 15ms epoch length is likewise tuned to the experimental network in the paper. When RTT is much larger, more transactions land in a single epoch and conflict handling gets more expensive. When it is much smaller, the delay the epoch introduces exceeds the round trips it saves. In a real deployment this value has to be re-derived against the actual RTT and the target commit latency.

The ordering rule is not free either. Ordering by tid and replica priority removes the dependency on NTP, but it leaves room for transactions from low-priority regions to be pushed back in re-execution repeatedly. Whether this turns into a fairness problem across regions is not addressed in the paper.

Summary

Epoch-based OCC raises the unit of coordination from the transaction to the epoch and removes the wide-area round trip from the commit path. Conflicts that surface late are not aborted. MWIS over the conflict graph picks the chains to keep, and only the remainder is re-executed deterministically in tid and replica-priority order. In the Minerva experiments the design held roughly 3.8x the throughput of CalvinDB at 200ms RTT, and latency moved only from 17ms to 18ms as replicas grew from 3 to 15.

The trade is that cost migrates toward re-execution as conflicts become frequent, and commit finalization stays tied to epoch boundaries. Workloads with large inter-region RTT that value throughput over individual response time are where this design applies.