Comment by arter45

Comment by arter45 a day ago

I don't have a lot of payment experience, but AFAIK actual payment systems work in an append-only fashion, which makes concurrency management easier since you're just adding a new row with (timestamp, from, to, value, currency, status) or something similar. However, how can you efficiently check for overdrafts in this model? You'd have to periodically sum up transactions to find the sender's balance and compare it to a known threshold.

Is this how things are usually done in your business domain?

mrkeen 21 hours ago

> how can you efficiently check for overdrafts in this model?

You already laid the groundwork for this to be done efficiently: "actual payment systems work in an append-only fashion"

If you can't alter the past, it's trivial to maintain your rolling sums to compare against. Each new transaction through the system only needs to mutate the source and destination balances of that individual transaction.

If you know everyone's balance as of 10 seconds ago, you don't need to consider any of the 5 million transactions that happened before 10 seconds ago.

(If your system allowed you to alter the past and edit arbitrary transactions in the past, you could never trust your rolling sums, and you'd be back to summing up everything for every operation.)

Reply View 4 replies

arter45 21 hours ago

So you're saying each line records the new value of the source and destination balance, rather than just the sum that is being exchanged?

Reply View | 3 replies
- mrkeen 18 hours ago
  
  No.
  At the beginning of time, all your accounts will have their starting value.
  When the first transaction (from,to,value) happens, you will do one overdraft check, and if it's good, you will do 1 addition and 1 subtraction, and two of the accounts will have a new value.
  On the millionth transaction, you will do one overdraft check, and if it's good, you will do 1 addition and 1 subtraction, and two of the accounts will have a new value.
  At no point will you need to do more than one check & one add & one sub per arriving transaction.
  (The append-only is what allows this: the next state is only ever a single, cheap step from the current state. But if someone insists upon mutating history, the current state is no longer valid because it no longer represents the history that led up to it, so it cannot be used to generate the next state - you need to throw it all away and regenerate the current/next states, starting from 0 and replaying every transaction again.
  
  Reply View | 1 reply
  
  arter45 18 hours ago
  
  Ok so basically you have a Transactions table as well as a separate Accounts table which stores balances, and every time Alices wishes to pay Bob, a (database) transaction appends an entry to the Transaction table and updates balance in Accounts only if the sender’s balance is ok? Something like a “INSERT INTO…SELECT”?
  
  Reply View | 0 replies
- awesome_dude 18 hours ago
  
  The rolling balance is a "projection"
  Your bank statement has the event (A deposit or withdrawal) with details, and to one side the bank will say, your balance after this event can be calculated to be $FOO
  The balance isn't a part of the event, it's a calculation based on the (cached) balance known from the previous event.
  Further, your bank statements are (typically) for the calendar month, or whatever. They start with the balance bought forward from the previous statement (a snapshot)
  
  Reply View | 0 replies