Demonstration / Financial state
Rewards Ledger: durable state for accruals, refunds, and reversals
An interactive rewards ledger failure lab with persistent IndexedDB tables, double-entry postings, idempotency receipts, ambiguous retries, refunds, reversals, projections, and reconciliation.
Interactive failure lab
Make the system survive reality.
Every action writes to browser IndexedDB. Journal entries, idempotency receipts, the balance projection, and the operational trace survive reloads while failures and corrections remain inspectable.
No rows yet. Settle a purchase, then reload the page—the record will remain.
The product problem
A reward balance looks simple until transaction lifecycles diverge. Authorizations can settle differently, refunds can be partial, reversals can arrive late, and messages can be retried. A mutable balance alone cannot explain how the current state came to exist.
The model
Represent every reward effect as an append-only event linked to its source transaction. Use idempotency keys at ingestion, explicit event types for accrual and adjustment, and a derived balance that can be rebuilt from the ledger.
- Never erase the original reward event.
- Link refunds and reversals to the event they adjust.
- Keep ingestion idempotent and processing replayable.
- Reconcile derived balances against independent source totals.
Operational evidence
Expose a customer-safe explanation and a deeper operational trace from the same event model. Useful diagnostics include source identifiers, processing attempts, event lineage, policy version, timestamps, and the reconciliation state.
What this demonstrates
Reliability is a product capability. The right financial-state model reduces manual support, makes corrections safe, gives customers defensible answers, and enables new reward mechanics without sacrificing auditability.