The classical paper-ledger bookkeeping is pretty much eventually consistent. They did not have the Internet when they invented it.

Flight booking is often statistically consistent only. Overbooking, etc.

▲

fauigerzigerk 5 days ago | parent [-]

>The classical paper-ledger bookkeeping is pretty much eventually consistent. They did not have the Internet when they invented it.

Absolutely. Bookkeeping is an offline activity (I'm only doing it once a year in my company, ha ha). You just have to make sure not to record the same transaction more than once, which could be non-trivial but shouldn't be impossible to do with CRDTs.

>Flight booking is often statistically consistent only. Overbooking, etc.

That may be acceptable in some cases but you still can't use CRDTs for it, because you need a way to limit the extent of overbooking. That requires a centralised count of bookings.

	▲	josephg 5 days ago \| parent [-]
		Most complex crdts are built on top of the simple crdt of a grow only set. Ie, what we actually synchronise over the network is a big bag of commits / operations / something such that the network protocol makes sure everyone ends up with all of the operations known to any peer. Then the crdt takes that big set and produces some sort of sensible projection from it. > You just have to make sure not to record the same transaction more than once So this should be pretty easy. Have a grow only set of transactions. Give each one a globally unique ID at the point of creation. Order by date and do bookkeeping. One thing you can’t guarantee is that the balance is always positive. But otherwise - yeah.