Let’s say I have a single action that updates a single “source of truth” canister, but this action has side effects that also update canisters for two additional users, allowing these users to quickly look up the result of this action.
This circumstance can be thought of as a “transactions API”, where multiple updates/insertions happen at once. In this case of a multi-canister architecture, there are two main approaches.
If it’s vital that the multiple changes all succeed or fail, then this must be an asynchronous API involving an intermediate canister that has a queue. Imagine that one of the 3 canisters is on a subnet that gets overloaded - we need a Kafka or SQS equivalent to accept and process requests with retry, and then to reject the update in the case of a subnet outage (Maybe send the failed request to a DLQ). All of this work must be done on the backend, using a intermediate “queuing canister”, which is a grant project in itself.
In the case that one or more update can be allowed to fail (in this rare outage condition), we can perform all of the updates coordinated by the frontend/client, with a built in ping and retry mechanism (that isn’t as resilient as a queueing implementation on the backend).
We haven’t even discussed the performance trade offs of these frontend/client vs. backend implementations - which definitely figure into the equation as well.
I’m curious if any of you have thought about how to solve transactional updates that involve multiple canisters, and some of the approaches you have taken (pokes @hpeebles).