Skip to content

Event Sourcing and As-Of Queries

On the Ordo financial state is never updated; events are appended. A contract’s balance today is derived deterministically by folding the events accumulated since establishment (payments, fees, allocation, delivery, restructuring…).

  • Auditability: The answer to “where did this number come from?” is the event chain that produced it. Because the chain is append-only, the answer is always definitive.
  • Replay: A correction appends a corrective event instead of erasing history. What was corrected, and when, is itself a permanent record.
  • Single source of computation: A balance is never “a stored number”; every channel derives the same result from the same events.

Most read endpoints support an asOf parameter, reproducing state with what the system knew on that day:

GET /api/v1/contracts/ctr_01J8ZK4T2M/statement?asOf=2026-03-31

The asOf=2026-03-31 response is computed with the event set as of the March 31 close — and with the rule-set versions valid and pinned on that day, not today’s. Audits and historical verification of BDDK reports rely on this mechanism.

{
"eventId": "evt_01J9AB3XKQ",
"type": "PAYMENT_SETTLED",
"occurredAt": "2026-08-20T09:14:33Z",
"contractId": "ctr_01J8ZK4T2M",
"payload": {
"amountMinor": 250000,
"currency": "TRY",
"installmentNo": 14
},
"actor": { "userId": "ops-user-1", "channel": "OPS_CONSOLE" },
"traceId": "8f4a2c1e-9b3d-4e7f-a1c2-5d6e7f8a9b0c"
}

Every event carries its actor, channel and traceId. Administrative actions (approvals, permission changes) live in the same ledger — the financial trail and the operational trail are never split.

The identity provider and the core API run on Cloudflare Containers; persistence is on managed Postgres:

  • the identity provider’s realm data,
  • the event store (the es.events table),
  • the audit trail.

The event-sourced ledger model is unchanged on this infrastructure: the ledger stays append-only, and state continues to be derived by folding events.