TLDR there's a database but POS systems just write events to it, not read. The article doesn't discuss checking balances, or preventing overdraw when multiple purchases happen at the same time. It mentions event durability on the POS, but the solution is hot backups.
Edit: Maybe I got this wrong. Maybe the point is that each POS communicates directly with the payment processor, in which case the above applies but wrt inventory instead of balances, and the mention of event sourcing is non sequitur. Also there's still a database, it's just the payment processor's database.
Comments
TLDR there's a database but POS systems just write events to it, not read. The article doesn't discuss checking balances, or preventing overdraw when multiple purchases happen at the same time. It mentions event durability on the POS, but the solution is hot backups.
Edit: Maybe I got this wrong. Maybe the point is that each POS communicates directly with the payment processor, in which case the above applies but wrt inventory instead of balances, and the mention of event sourcing is non sequitur. Also there's still a database, it's just the payment processor's database.
And the consumers of the event stream still need to have a database to deal with state management. So you're just moving the database elsewhere.