Why This Inventory Uses Events Instead of Overwriting Facts

Keep the reason behind the number

Changing a quantity from three to two is easy. Explaining that change a month later is harder. The Inventory System keeps an append-only asset_events ledger, so missing items, quantity changes, and expiration decisions can be traced to actions instead of guessed from the latest row.

Derive the current state from evidence

The architecture then derives operational views from that ledger. asset_state holds the current reconciled projection needed by scans, queues, and the browser UI. asset_state_history preserves prior projection versions for audit and experimentation. Read-oriented surfaces—action queues, exports, state comparisons, and the UI—form a final layer optimized for decisions rather than raw storage.

From an action to a useful answer

An event stays in the ledger while projections make its consequences easy to read.

flowchart TD
    Action[Scan or quick action] --> Ledger[Append event]
    Ledger --> Current[Reconcile current state]
    Current --> History[Retain projection history]
    Current --> Views[Queues and browser views]

Immediate interactions without losing history

Projection happens synchronously when an event is written. That keeps a label scan or quick action immediately useful while preserving the ability to replay events later. Administrative tools can compare stored state with a fresh replay or rebuild projections from the ledger, which makes future changes to expiration, confidence, and queue logic safer to evaluate.

Idempotency protects that model at the interaction boundary. Quick-action forms and API writes can carry idempotency keys, preventing an accidental double-submit from becoming two ledger events. The result is a system that remains approachable at the shelf while retaining the auditability expected from a much more formal data platform.