Deterministic transaction ordering

Calvin’s design replicates an ordered transaction input stream and uses deterministic scheduling to avoid a conventional distributed commit agreement phase for its supported execution model. Participants can know which conflicting transaction should precede another before holding the transaction’s locks. This changes the contention footprint. It does not mean a partitioned machine can ignore the agreed plan, or that a node failure authorizes a new outcome. Recovery and replay must follow the same input and ordering commitments.

Execution need not be globally single-threaded. Nonconflicting transactions can overlap, and separate shards can perform their portions while preserving the required conflict order. Distinguish the order of logical effects from wall-clock instruction interleaving. If two transactions touch independent records, forcing one to finish entirely before the other starts can waste parallel capacity. The scheduler needs enough information to identify their accesses and coordinate dependencies, rather than granting unlimited parallelism and hoping the final outputs match.

Wall-clock reads, random choices, external API results, unordered iteration, and application-version changes can all create different outcomes from apparently identical requests. A deterministic design must eliminate such differences, record them as agreed inputs, or provide a supported mechanism to resolve them consistently. Replaying an external payment call is especially dangerous because deterministic arguments about database state do not make the outside service idempotent. Define which effects belong to the replicated transaction and which need a separate delivery protocol.

Calvin’s scheduling depends on obtaining transaction read and write sets in advance. Data-dependent access can require a reconnaissance or planning mechanism and validation of what it discovered; it is not free support for arbitrary interactive transactions. Preserve the distinction between a business rule that deterministically declines a request and a system-level abort caused by execution uncertainty. A replay must reproduce the authorized logical behavior, while failures and membership changes follow the surrounding replication and recovery rules.

An ordering position needs a stable identity across epochs, replay, and log compaction. A small wrapping slot number cannot identify an unlimited history by itself. Keep the epoch, sequence, or other protocol context that distinguishes reused positions. Observe ordering latency separately from execution and dependency waiting: a fast execution engine can still queue behind a saturated input-ordering service. Evaluate recovery time and access-planning overhead as well as steady-state throughput under the workloads the design actually supports.

The modular lab makes the label-reuse issue concrete. Reset, set modulus to 4 and additive step to 1, predict when the displayed residue returns to zero, then Step four times. For a fresh comparison, Reset and explicitly set modulus to 5 and additive step to 1, predict, then Step five times. Each Step advances one addition. This is a finite additive orbit, not Calvin’s sequencer or a transaction log; explain why returning to label zero does not mean the previous operation at zero is the same operation.