StateVec is an in-memory deterministic execution engine for business systems where ordering, atomic state change, audit, and replay matter.

It is not meant to replace every database, queue, or service framework. The goal is narrower: move the critical mutation path into one controlled runtime, then let databases, queues, caches, and analytics systems serve the surrounding projection and integration work.

At a product level, the promise is simple:

  • Simpler: business developers describe domain records, commands, events, keys, indexes, and invariants in a DDD-style model, then write the domain logic against that model.
  • Faster: the runtime can execute against an efficient in-memory layout, stage results speculatively, and optimize the batch pipeline around one deterministic execution contract.

The system boundary

Many business engines already have a state engine inside them. It is just spread across handlers, database transactions, retry code, cache updates, queue publication, and repair scripts.

StateVec makes that boundary explicit:

command
   |
   v
deterministic runtime
   |
   v
state delta + events + TxResult
   |
   v
TxLog
   |
   +--> replay
   +--> audit
   +--> readonly projection
   +--> downstream publication

The domain still owns the business rules. StateVec owns the execution contract: ordered command handling, canonical state mutation, durable result history, and replayable state transitions.

Simpler domain development

StateVec follows a domain-driven design shape: the business model is expressed as records, commands, events, uniqueness rules, indexes, and invariants. The domain logic should read like the business problem, not like database plumbing.

In many service architectures, the same business fact moves through several formats:

protobuf command
   |
   v
service DTO
   |
   v
domain object
   |
   v
database row / checkpoint
   |
   v
event payload

That conversion chain is familiar, and it works. But for critical state engines, it creates a lot of incidental work: schema drift, object mapping, checkpoint conversion, retry behavior, replay tools, and repair scripts.

StateVec tries to remove that repeated conversion from the hot mutation path. Domain code works against generated accessors over the engine-owned state model. The runtime handles layout, staged writes, TxResult construction, replayable history, and cluster-facing execution details.

The goal is that business developers spend more time on business rules:

  • what the command means;
  • which records it can read or mutate;
  • which invariants must hold;
  • which events should be produced;
  • what the result means for audit and replay.

They should not need to hand-build the mechanics of state storage, transaction result tracking, replay bookkeeping, or cluster operation for every engine.

Faster execution path

StateVec is designed for high-throughput ordered execution, but the speed does not come from a single trick.

There are three important pieces.

First, the runtime owns the in-memory layout. Instead of building large object graphs and repeatedly translating between wire objects, domain objects, and persistence objects, execution can operate on compact engine-managed records and generated accessors.

Second, StateVec uses speculative execution. A command can be executed into a staged result before crossing the durable boundary. If it fails, the staged state disappears. If it succeeds, the TxResult becomes the committed unit for state, events, audit, replay, and verification.

Third, the runtime can optimize the batch pipeline around the fact that commands share one deterministic execution contract. Ingestion, execution, durability, publication, and readonly projection can be shaped as pipeline stages rather than a loose collection of service handlers and database calls.

The practical result is not just raw speed. It is a simpler performance model: fewer conversion layers, fewer ad hoc coordination paths, and a clearer boundary between candidate execution and committed history.

Business-defined state

StateVec state is defined around the business domain:

  • records;
  • commands;
  • events;
  • unique business keys;
  • indexes and prefix lookup paths;
  • invariants that must hold during execution.

The intent is to give domain developers a precise state model without forcing them to rebuild storage layout, mutation bookkeeping, replay behavior, and audit trails by hand.

Deterministic execution

The execution path should be narrow:

input command
   |
   v
read current state
   |
   v
run domain logic
   |
   v
produce state delta + events
   |
   v
commit TxResult

If a command is rejected, the staged changes disappear. If a command is committed, the result becomes durable history. This makes failure handling simpler because the system has a clear boundary between a candidate execution and a committed transition.

TxLog as source of truth

StateVec records committed execution results, not just opaque writes.

A useful TxResult includes:

  • the input command identity;
  • the state changes produced by execution;
  • emitted events;
  • command sequence and transaction sequence;
  • verification material for replay or cluster comparison.

The TxLog is the durable source of truth for the execution history. Projection, audit, replay, and recovery should be derived from that committed history rather than reconstructed from scattered service logs.

Query surfaces

StateVec is not trying to become a general-purpose SQL database.

The planned query path is built around readonly projections. Instead of forcing every read through the write runtime or a relational reader, StateVec can maintain business-facing projection views for the query surfaces a product actually needs.

The query model is based on business-defined state views:

  • direct record lookup;
  • unique-key lookup;
  • index lookup;
  • prefix scan over known access paths;
  • readonly projection views.

This gives the product layer flexibility. A matching engine, ledger, inventory system, or entitlement service may expose different read models to different consumers:

  • HTTP APIs for request/response lookup;
  • gRPC APIs for low-latency internal services;
  • WebSocket streams for push-style state updates;
  • batch or export paths for downstream analytics.

For many operational systems, these query paths cover the hot state queries that would otherwise put pressure on database readers or cache layers. Relational databases can still be used for broader reporting, analytics, ad hoc inspection, and long-lived projections.

Where it fits

StateVec is designed for systems where the correctness of state transitions is the product:

  • matching engines;
  • ledgers;
  • settlement workflows;
  • inventory reservation;
  • entitlement and quota systems;
  • risk engines;
  • order management;
  • other ordered business workflows.

These systems usually care about the same questions:

  • What command changed this state?
  • What state did the command read?
  • What delta did it produce?
  • Which events came out?
  • Can the result be replayed?
  • Can another node verify the same result?

StateVec makes those questions part of the runtime contract.

What remains outside

StateVec does not remove the rest of the platform.

Databases still matter for projections and reporting. Queues still matter for delivery and integration. Caches can still matter for edge-serving and non-critical acceleration. Observability, deployment, schema evolution, and operational tooling still need engineering work.

The difference is that these systems no longer have to own the critical mutation path.

Current direction

The current public direction is:

  • schema-defined records and access paths;
  • deterministic command execution;
  • TxLog-backed durable history;
  • replay and audit as first-class surfaces;
  • HA-oriented runtime shape;
  • readonly/projection query paths;
  • performance evaluation published as the runtime matures.

The architecture overview will go deeper into runtime roles, replication, projection, and deployment models. This page is the short product-level map.