The core cluster owns business state. Read-side extensions, called projectors, turn committed transactions into query views, notifications and decision inputs. The projector plugin framework is available; integration with non-voting replicas, called learners, is in development. Learners receive the committed history without voting, and projectors build views from it.

Commands and replicationAsynchronous views, outside voting decisions
StateVec transaction core and read-side extensionsBusiness clients submit batches of commands to the leader. The leader and two voting followers run the same plugin. In Verify mode, followers verify execution and persist the log before acknowledging replication. Each node keeps a command log, executes business logic and writes recovery snapshots in the background. Non-voting replicas do not count toward the quorum. Read-side extension integration is in development. Changes suggested by an extension must be submitted as new commands. Remote backup tools run separately.Channels / APIs / ServicesRetain original requests for recoveryClient connectionsBatch requests → ordered processingFinal business resultLost replies need recovery; auditing needs archivalStateVec transaction coreVerify mode by default / Performance mode by explicit choice · One committed historyLeader · Business pluginSimulate → replicate → update stateCommand log + snapshot writerFollower A · Same pluginVerify → persist → acknowledgeCommand log + snapshot writerFollower B · Same pluginVerify → persist → acknowledgeCommand log + snapshot writerA quorum decides when to commit; nodes update state in order. The core runs on local storage, with no remote-storage calls.Replicate log / Restore snapshotLearner · Non-voting replicaConsume committed transactionsMay lag; no role in write decisionsIntegration in developmentRead-side extensions · Plugin frameworkQuery viewsAccounts / Search / ReportsQuery store of your choiceEvents & pushSubscriptions / IntegrationReplay and deduplicationReal-time decisionsRisk / Rules / AlertsSubmit proposed changes as commandsChange core state? To change core state, submit a new command; the core validates it.Operations tooling off the commit path: backup, upload, cleanup and offline recovery preparation. Remote failures stay outside transaction commit;local I/O failures must still be classified and handled correctly.
The core flow shows Verify mode; in Performance mode, business logic executes after commit. Learner integration for read-side extensions is in development. Dashed components build asynchronous views and do not vote on writes. Write sharding requires a separate design. Scroll horizontally on narrow screens.

One history for recovery

Recovery starts from a verified snapshot and replays the committed commands that follow it. The node keeps a single authoritative command log.

Background recovery snapshots

A dedicated thread encodes, validates, writes and reads back each snapshot, and the cluster then adopts the completed result. Log writes and Raft’s persistent election and commit state are still synced to disk as required.

Ordered requests and automatic reconnection

Each client has one outstanding batch and keeps its result until the application retrieves it. On connection failure it tries each configured node in turn. Synchronous, background-thread and async APIs share the same recovery rules. Independent request sequences use separate clients, and each node accepts up to 32 client connections.

One authoritative source, multiple views

Projectors derive views from committed facts; a view can never authorize or overwrite core state.

Resource planning for projection workloads

Projection on learners still consumes CPU, disk and network bandwidth. Plan explicit resource budgets and measure catch-up and extension workloads.

Decisions re-enter through commands

A projection can recommend an action, but any change to core state must be submitted as a command and validated by the core. Rules that gate admission must run in the core, because projections may lag.