sidnt / zionotes

⸮ 🔴zio notes | zio nursery 🔵?
0 stars 0 forks source link

money transfer #19

Open sidnt opened 4 years ago

sidnt commented 4 years ago

imagine money transfer only as changing entries in a ledger. the system has fixed money and we don't want to create or destroy money in the system. neither do we permit negative balances.

to consummate a 2 party transfer, an accountant must do both - debit the source account AND credit the target account - correctly. anything else brews chaos. by correctly, we mean, that negative balances shouldn't happen. and the total debit amount is exactly equal to the total credit amount.

there can be multiple accountants operating on the ledger. the accountants have free access to mutate the ledger. the accountants don't get to interact with each other though, neither can they know or see each other. they can only interact with the ledger. also, they don't get to block each other. we assume that the mutation happens in such a manner, that a situation where two accountants are trying to mutate the same ledger entry at the same time, doesn't happen.

what code does the accountant follow to do the transfer? turns out there are multiple ways to conduct the transfer, where one way == one sequence of instructions. what's singleton here though, is the instruction for the transfer, which has only 3 atoms of information, the debit account, the credit account and the transfer amount. this is the information that an accountant gets from the account owner. by singleton, we mean that there one and only one way, only one format in which this instruction is found. this is the instruction card (an analogue of cheque) that an accountant receives to begin its work.

an accountant gets the transfer instruction.

a naive transfer implementationA = {

  ∙ read the source account balance
  ∙ check if it's sufficient to cover the transfer
  ∙ calculate the resulting debit account balance post debit
  ∙ mutate the debit account balance in the ledger (ie, commit the debit, in the ledger)
  ∙ calculate the resulting credit account balance post credit
  ∙ mutate the credit account balance in the ledger (ie, commit the credit, in the ledger)
  ∙ return and signal completion

}

money recorded in the ledger, can be redeemed in whatever it is backed by. eg, physical gold, or paper notes.

paradigmA - money transfer only ever means transfer of enforceable ownership rights over physical tokens, eg banknotes or metal coins. accounting happens as the physical artifact itself.

paradigmB - money transfer mean changing entries in a ledger. accounting happens by reading the entries from the ledger.

sidnt commented 4 years ago

that implementationA is perfect if there was one and only one accountant operating on the ledger. but if there are multiple accountants, implementationA can break the system, violate the constraints required and result in an inconsistent system state.

an example mistake scenario using implementationA = {

let's suppose there are only two accounts in the ledger. accountA (owned by personA) has 10 bucks and accountB (owned by personB) has 0. so total money in the system is 10.

if personA instructs 5 accountants simultaneously, to transfer 10bucks from accountA to accountB, the completion of this requisition can result in non deterministic results, which can be different each time, depending on how the accountants interleave with each other's work, on how their work is scheduled. ideally, at the very least, the results should be deterministic. at the very best, all required constraints should be respected by each operation.

simultaneously is the keyword here. all the accountants involved, receive instruction simultaneously. but since there's only one single ledger, and since nothing has been enforced about the ordering of their work, there are several things that are left non determined at the outset here. in particular, who gets to work first, whether they get to execute every single line of instruction at once, or whether they execute some, and then someone else takes over, and then someone else, until each accountant returns and signals completion to the requisitioner, until every accountant returns.

a simple execution scheduling (in a breadth-first fashion) can make each accountant execute one line of instruction, and

if personA instructs 5 accountants simultaneously, to transfer 10bucks from accountA to accountB,

}

sidnt commented 4 years ago

breadth-depth-first-execution200