Command ATransfer $80
Reads $100Decision validCommitted
Writes at position 43. The account balance is now $20.
The stale-decision problem
Correct business logic can still commit the wrong result.
Two commands can read the same valid state and both make a reasonable decision. The second decision becomes unsafe when the first command changes the facts it relied on. Orisun makes that race part of the write contract.
Declared contextAccount balance $100
position 42Command BTransfer $60
Read $100Was valid at 42Rejected
ALREADY_EXISTS: re-read the context and decide again.
Without the checkBoth transfers land and the account reaches -$40.With OrisunThe stale second write never commits.
What changes
History becomes an active guardrail, not just an audit trail.
Orisun closes the loop between the evidence a command reads, the decision in application code, the atomic write, and the systems that react afterward.
Preserve how the system got here
Keep the events behind current state so decisions, projections, audits, and future models share the same durable source of truth.
Refuse decisions made on changed facts
A command declares the events it relied on. Orisun checks that same subset inside the write transaction and rejects a stale save.
Match the real business invariant
Define consistency with event-content queries across the relevant entities instead of forcing every rule into one fixed stream.
Recover and continue from every commit
Durable checkpoints provide no-skip, sequential publishing per boundary. Subscribers catch up from storage before moving live.
Where it matters
Use the facts that make each decision safe.
The application still owns its domain rules. Orisun gives each command a dynamic, content-defined consistency boundary for enforcing them under concurrency.
Payments and ledgers
Two transfers are each valid against the same balance, but not together.
Validate the source balance and both account histories before committing both legs atomically.Inventory and reservations
Concurrent requests act on availability that another request has already consumed.
Scope the write to the product, reservation, and allocation events that determined availability.Workflows and approvals
A step is approved after policy, permissions, or an earlier decision has changed.
Check the workflow and policy events the command evaluated before recording its outcome.Agent actions
An agent proposes an action from facts that changed while it was reasoning or waiting on a tool.
Record the relevant facts as events and reject the action when its declared context is no longer current.One command loop
Read, decide, validate, deliver.
Business decisions stay in application code. Orisun owns the transactional context check and the durable path from a committed event to every recovering subscriber.
Read the evidence
Query one consistent snapshot of the event history the command needs.
Make the decision
Apply business rules in application code and produce the next events.
Validate and commit
Save only if the same declared event subset is still at the expected position.
Deliver the result
Publish sequentially per boundary, with storage-backed catch-up before live delivery.
The mechanism
Consistency shaped around each command.
Command Context Consistency lets each decision declare the exact event subset it relies on. Query that context, remember its position, then save only if it remains unchanged. Define and activate the application boundary through the Admin API before entering this command loop.
Node.jsRead and save with the same criteria
const latest =
await client.getLatestByCriteria({
boundary: 'accounts',
criteria,
});
const expectedPosition = latest.contextPosition;
await client.saveEvents({
boundary: 'accounts',
query: {
expectedPosition,
subsetQuery: {criteria},
},
events,
});
Built as one system
The durable log and delivery path share one ordering contract.
Storage remains the source of truth. Embedded JetStream is the live delivery layer, while durable publisher checkpoints ensure committed events are not skipped. Publishing is at least once and sequential within each boundary.
- Transactional event writes and context checks
- Runtime boundary creation through a durable event-backed catalog
- Durable per-boundary publisher checkpoints
- Storage-backed catch-up before live delivery
- gRPC, auth, indexes, telemetry, and admin APIs
Deploy your way
Keep the API. Change the operational shape.
Start with a complete SQLite server, then use PostgreSQL, YugabyteDB, or the FoundationDB beta backend when the deployment needs multiple nodes or distributed storage.
SQLite
Open guideSingle-node production, embedded applications, edge services, and local development.
- one active node
- JSON criteria
- durable checkpoints
PostgreSQL
Open guideMulti-node Orisun deployments with mature database operations and shared storage.
- cluster locks
- schema boundaries
- PgBouncer
YugabyteDB
Open guideDistributed SQL through the PostgreSQL-compatible backend and committed-watermark reads.
- YSQL
- advisory locks
- stable-prefix reads
FoundationDB
Open guideBeta clustered backend with ordered key ranges and parallel commits.
- versionstamps
- fenced leases
- covering indexes
Start locally
A complete event database in one SQLite container.
Run the event log, context checks, publisher checkpoints, admin state, and embedded JetStream together. The same EventStore API carries forward to every backend.
SQLitelocalhost:5005
docker run --rm \
-p 5005:5005 \
-e ORISUN_BACKEND=sqlite \
-e ORISUN_SQLITE_DIR=/var/lib/orisun/sqlite \
-e ORISUN_NATS_CLUSTER_ENABLED=false \
-e ORISUN_ADMIN_BOUNDARY=orisun_admin \
-v orisun-data:/var/lib/orisun \
orisunlabs/orisun:0.6.1-sqliteDocumentation