StateVec offers two execution modes for the same deterministic business plugin. Verify mode is the default and checks execution results before commit. Performance mode runs business logic after commit, shortening the pre-commit path.
The same transaction foundation
Both modes use Raft to establish one ordered, durable transaction history. Each command is a transaction: its record changes are installed together on success, while a business rejection leaves its records unchanged. Commands execute serially against the effects of earlier commands.
Both validate request structure before admission, perform the required log writes and disk syncs, and recover from a selected checkpoint plus the committed Raft log. Performance mode retains these guarantees while shortening the pre-commit path.
Full Consistency · Verify mode
Verify mode adds execution agreement to the replication path. Use it when independent verification of business results is a priority, such as balances, ledgers, settlement and limits.
- Simulate. The leader runs the commands from a known starting state and computes expected outcomes and hashes. Simulation does not install business changes.
- Verify and persist. Voting followers independently execute the same commands and compare their results with the leader’s. They satisfy the required persistence barrier before acknowledging replication.
- Commit. Raft commits once a quorum acknowledges. A follower that fails verification cannot acknowledge that replication; the cluster does not automatically switch to Performance mode.
- Apply and respond. Each node applies the committed commands. Verified simulation results can be reused only when the starting state, inputs and expected results match exactly; otherwise execution is repeated and checked.
Verify mode detects execution divergence between replicas. It depends on deterministic, trusted plugins; a business-rule defect shared by all replicas still requires application testing. A single-voter cluster has no independent follower verification.
Extreme Performance · Performance mode
Performance mode removes simulation and execution-result comparison from the pre-commit path. Use it when throughput is the priority and the application accepts execution after commit without that independent pre-commit check.
- Validate. Check the request’s structure and encoding before admission.
- Replicate and commit. Persist commands through Raft with the same required disk syncs and quorum commitment.
- Execute and respond. Run the committed commands in order, install successful changes, and produce business outcomes and a hash-linked transaction history.
A business rejection is a normal outcome and leaves that command’s records unchanged. An execution fault on a committed command stops the node and preserves committed history for recovery.
Performance mode computes transaction-chain hashes during execution. It omits the pre-commit result comparison used in Verify mode, and background cross-replica chain sampling is not currently provided.
Choose the verification path
| Guarantee or behavior | Full Consistency · Verify mode | Extreme Performance · Performance mode |
|---|---|---|
| Raft ordering and quorum persistence | Provided | Provided |
| Atomic command execution and serial order | Provided | Provided |
| Execution before commit | Leader simulation and follower verification | Business execution begins after commit |
| Independent result comparison before commit | Voting followers compare results | Omitted |
| Final response | After committed apply | After committed apply |
| Recovery | Selected checkpoint and committed log | Selected checkpoint and committed log |
Start with Verify mode when verification is the main requirement. Choose Performance mode explicitly when the shorter pre-commit path suits the workload. Compare throughput and completion latency under the same commands, batch sizes and storage configuration; the published measurements report both modes.
Both modes return each command’s business outcome after the complete batch is applied. Batching shares replication costs across commands; it does not turn the batch into one all-or-nothing transaction. Asynchronous query views can lag behind the transaction core in either mode.
References and examples
- Raft history and recovery: ordered commitment, execution verification, durability and recovery.
- Bank plugin example: atomic Deposit, record revisions and the execution sequence in Verify mode.
- Plugin contract: deterministic business logic and transaction boundaries.