Once you add parallelism to your transaction processing, all manner of untoward things can happen. For example, two parent processes may attempt to execute the same transaction to acquire the same resources at the same time, having failed to exchange messages to ensure their internal household state is fully synchronized. And sometimes child processes will fail to acquire permissions but silently commit transactions anyway!
This week my toddler spent $60 on a 11x14 inch canvas print of himself getting a bottle of ketchup out of the fridge. $20 was for priority shipping to ship it to our former address in a different city.
I thought the photos app was a fairly innocuous form of screen time, not realizing that it was so easy to make a purchase! No password confirmation or anything.
Fortunately support made a one-time exception and refunded the payment even though it was well past the cancellation window.
I still removed all the payment methods and addresses from our Google Pay account because I couldn't figure out any other way to guarantee that this doesn't happen again.
Frictionless payment flows do not mix well with toddlers.
I understand that concurrent edits to the ledger will become problematic. If this really is a requirement, a distributed ledger solution (cloud based tool) may be needed
Though is the root issue just communication? At some point transactions need:
1. Recorded
2. Categorized (optional, but desirable)
3. Reconciled (This can only happen as often as bank statements are issued)
With multiple spenders, communication (to answer the question "what is this transaction for?!?!") is paramount and fits naturally at the reconciliation step or more frequently if desired.
The workflow described is synchronous, centralized and simple
