Runtime for business-critical systems
Run accounts, orders, positions, risk checks, and ledger workflows in memory with deterministic execution, replay, audit, and lower infrastructure cost.
Origin and team
"Jacky is one of the most technically uncompromising engineers I have worked with. He ran a complete trading service stably at 10% of the AWS cost."
CTO of a top-10 exchange
Fintech systems architect with more than 15 years in financial technology and more than 10 years designing high-performance distributed systems.
The first problem was not a database problem. It was a reliability problem: a critical engine had to explain decisions, recover state, and replay its committed path without depending on scattered logs.
Read the storyA SQL record-delta explorer revealed a better boundary: canonical servers own state change, while readonly projectors own verified external effects, including publication.
Read the storyFor a large trade engine, business logic is only the center. The harder work is message ingestion, restart recovery, consistent snapshots, failover, event publication, and downstream projections.
Read the storyThe strongest pilots are systems with explicit business state: trading, ledger, settlement, inventory, risk, or any workflow where replay and audit should be first-class.
Request pilot accessAWS cost model
StateVec runs the critical transaction path on smaller hardware and serves state queries from readonly projections, reducing round trips through the primary database tier.
Peak 100k TPS business engine model with replicated shard groups, Kafka, and local instance SSD.
Directional model; excludes storage, I/O, network, and managed-service markups.
10k TPS write model with comparable state-query capacity through Aurora readers or StateVec readonly projections.
Directional model; excludes Aurora storage, I/O, network, and backups.
Business source of truth
Business value depends on reliable data and reliable data transitions. StateVec keeps the transaction history close to the business meaning: what changed, why it changed, and which command made the result durable.
Reliable storage, but it rarely explains where a value came from.
Useful while running, but lost on restart.
Fast lookups, but usually not the source of truth.
Preserves event flow, but not the full reason behind each business change.
May show what happened, but the details are often fragmented.
May keep its own version of truth, creating reconciliation work.
Speculative execution
Run a command through deterministic logic, produce a TxResult, apply the state delta, emit the event, and replay the same committed path from TxLog.
Start the simulation to watch a command become replayable history.
Blog
Deep dives on performance, deterministic execution, replay, audit, and the design choices behind the engine.
What StateVec is, where it fits, and how execution, replay, and query surfaces work.
Read overviewCompute the TxResult before crossing the durable boundary.
Read blogMake records, unique-key lookup, and indexes transaction-visible during execution.
Read blogTreat committed TxResults as durable history for state, events, replay, and verification.
Read blogAccess
For teams building trading, ledger, settlement, inventory, risk, or other transaction-heavy engines.