4 ms·
I was more interested in latency of a strict serializability RSM like TigerBeetle. I was thinking that maybe my use case is maybe something which should not be
by weitzj 5y ago
I was more interested in latency of a strict serializability RSM like TigerBeetle.
I was thinking that maybe my use case is maybe something which should not be solved in the ledger directly, but merely the ledger should offer an API to fulfill transactions in the ledger. And the Api consumer has to provide an idempotency key to perform the transaction .
But then again I would assume that the ledger would have to provide an endpoint what the current balance is (the sum over all transactions). And when the api consumer makes a decision depending on KYC and current balance, whether to try to record a transaction on the ledger, in the meantime the balance could have changed.
So maybe one could send an idempotency key and the balance which was used to decide whether to fulfil the transaction.
Or a more generic version: an api consumer could send an idempotency key and a smart contract compute kernel on a transaction request. And the smart contract gets evaluated on the fly with the live data inside the ledger.
I smell like I am inventing a database and SQL here. ;)
Regarding: “ KYC would then be required before customer A can receive any more gifts ”
Where would the validation live? Inside the ledger as a contract per customer across their accounts?
When customer B tries to send money to customer A and A fails: what will customer B see? An immediate error or an asynchronous message
- jorangreef 5y ago"I was more interested in latency of a strict serializability RSM like TigerBeetle." The back-of-the-envelope calculation for the latency per 10,000 transfers would be: RTT from leader to the fastest follower + ms to send 1.2 MiB over a 1 Gbps or 10 Gbps network + ms to fsync 1.2 MiB on NVME And multiple transfer batches are pipelined or overlapped by the leader to the followers (we're working on pipelining at the moment) to amortize network transfer. The cross-region replication can be asynchronous (configurable) which is also how I believe LMAX do it, or you could have your backup region be a few hundred miles away as with AWS regions. "But then again I would assume that the ledger would have to provide an endpoint what the current balance is (the sum over all transactions)." Exactly. One of TigerBeetle's contributions is to colocate data and policy across a chart of accounts. It's different from a "ledger" in that TigerBeetle is not only accounting books but also accounting policy. The system of record is the optimal and safest place to make decisions, and this avoids the overhead of distributed transactions. This provides a 50% throughput improvement just by cutting out the unnecessary interim query. Instead of amplifying network queries to make decisions away from the data, you design a chart of accounts with simpler primitives to control transfer flows between them. For long-lived transactions that span multiple external systems, TigerBeetle provides two-phase transfers as atomic primitive, which is what many payment systems use, as I am sure you would know. These two-phase transfers also support 256-bit SHA256 hash locks, e.g. ILPv4 conditions, which I think could be used to support some interesting logic outside the database. This all enables the application layer to be completely stateless and scaled shared nothing. You could literally spin up a hundred API instances in front of TigerBeetle, all shared nothing and ephemeral. "When customer B tries to send money to customer A and A fails: what will customer B see?" An immediate error: "exceeds_debits". This can trigger the KYC user flow to be queued in an external message broker service. You can see exactly how this all works here: https://github.com/coilhq/tigerbeetle/blob/main/src/state_machine.zig#L291-L355 https://github.com/coilhq/tigerbeetle/blob/main/src/state_ma...
- weitzj 5y agoThanks a bunch for these detailed answers. In a previous job I guess TigerBeetle was the thing I was searching for. Maybe this link is also interesting for you https://news.ycombinator.com/item?id=20921572 https://news.ycombinator.com/item?id=20921572
- jorangreef 5y agoHey, thanks for the detailed questions (and link to WaltzDB)!