Glossary
Event-sourced POS
event log · append-only ledger
An event-sourced POS records every action as an event in an append-only log (item added, item voided, payment taken, order closed) and derives every screen and every report from that log, so that nothing is ever edited in place and the history of a sale is the sale.
The log is the truth
A conventional system stores the current state of an order and overwrites it as it changes. An event-sourced one stores what happened, in order. The current state is a projection rebuilt from the events, and any past state can be rebuilt too. A void is a new event with a reason, not a deleted row.
What it buys a restaurant
An audit trail that a manager, an accountant or a tax inspector can read in order. Reports that are always consistent with the tickets, because both come from the same log. Devices that catch up after a disconnection by replaying the events they missed, rather than merging two edited copies of a table.
What it costs
Discipline. Every action has to be a well-defined event, and the shape of an event cannot be changed casually because old logs must still replay. It is a choice made once, at the start, or not at all.
How Brindola does it
Brindola's core is an event log in a local database on the master device. Commands are validated, appended, projected and broadcast in one process; replicas replay what they missed. Every report, receipt and close is a projection of that log, and replays are deterministic by test.