indexes = function(data)
query = function(indexes)
How does this model a classic banking app where you need to guarantee that transfers between accounts are atomic? indexes = function(data)
query = function(indexes)
How does this model a classic banking app where you need to guarantee that transfers between accounts are atomic?The atomic bank transfer is done as part of function(data). The data record contains fromAccountId, toAccountId, and amount. The function applies the transfer if it's valid (fromAccountId has at least that amount of funds), and no-ops otherwise.
It seems that you cannot, in one database call, make a transaction?
You would need to push your transfer to the depot, then poll until it has been accepted.
If you do not poll, then your transaction may be written but as a no-op.
Does this increase latency for such applications?
Note that depot appends can be done with "acking" so as not to return success until all colocated stream ETLs have finished processing the record. Stream ETLs also take only a handful of millis to complete. This is how you would coordinate a front-end with many tasks like you typically do with databases today (e.g. registering an account, updating a profile, adding something to a shopping cart, making a friend request, etc.).
This example uses microbatching because getting cross-partition transactionality with streaming is quite a bit harder, as streaming has either at-least once or at-most once semantics depending on how you configure it. Microbatching is always exactly-once semantics regardless of any failures that happen during processing.