In the banking transactional set ups I am familiar with, a transaction doesn't succeed unless there is sufficient balance, and if not, check if there is sufficient overdraft protection, or an alternate account from which funds can be debited.
Are these possible to do in a tigerbeetle setup before the debit/credit transaction is recorded?
What I am trying to say is, if it is merely recording debit/credits, it is basically a log of desired transactions.
Applying that log requires a possibly extensive series of checks and multiple accounts in practice, which can fail, and you'll have to issue a compensating transaction. Much more messy than if the check were done before committing the transaction.
And so TB exposes a set of primitives designed around debit/credit (not only a record of debit/credits).
For example, you can express something like:
- Do a transfer between accounts, but only on condition that the resulting debits would not exceed credits (or vice versa, or some threshold amount compared to this net balance), and while taking other authorized (but not yet captured) inflight transfers (i.e. to other third party systems using two-phase commit protocol) into account also in that net balance calculation.
- Then, if this transfer succeeds, immediately also do another 7000 transfers, all linked atomically together. But if any of these would fail, then the whole chain, including the net debit cap transfer, should not be executed.
- But only do all the above, if both volume and velocity limits (expressed not in a currency but in a quantity) in an isolated risk ledger would also be satisfied.
- And finally, if all this does succeed, then do another set of transfers in a separate USD reporting ledger.
You can do the above, atomically, in a single round-trip to TigerBeetle. It would be a nightmare in SQL.
But the other advantage to having the transaction DBMS speak debit/credit accounting primitives is that your multiple products can then build around a transaction processing core with strict controls, while keeping the accounting policy in the product layer above—because while every business/product may have different accounting policy, the primitives are the same. This keeps the core of your transaction DBMS simple and in control, while allowing flexibility for product evolution.
Are these possible to do in a tigerbeetle setup before the debit/credit transaction is recorded?
What I am trying to say is, if it is merely recording debit/credits, it is basically a log of desired transactions.
Applying that log requires a possibly extensive series of checks and multiple accounts in practice, which can fail, and you'll have to issue a compensating transaction. Much more messy than if the check were done before committing the transaction.