High Availability using Active/Active Multichain nodes with off chain work

Question

What are the options to achieve redundancy when polling for transaction and acting upon the transaction off-chain?

Here is the use case using atomic exchange as an example.

Step1: Address1 prepares an offer/ask exchange.

Step2: Address1 communicates the blob to Address2 via stream

Step3: Address2 polls the stream for the blob sent in step2. Address1 acts upon the offer before responding, such as making an off-chain call to debit credit card.

Step4: Address2 completes the exchange and sends the transaction.

All of the above should work - although I'm open to a better option than polling. However, to be robust I would like step3 to be Active/Active redundant using multiple multichain nodes. In Active/Active all pollers will debit the credit card. Having two multichain nodes in Active/Passive would work but there would be delay in making the Passive one Active.  

The only solution I can think of is for each polling node to write to a queue, and the queue listener keep track of whether its serviced the request. I'm hoping for something more elegant. Does the blockchain use case fall off the rails as soon as you need to go off-chain? Also, is there something better than continually polling the chain in step3?

Answer 1

First, instead of polling, you can use a walletnotify script to be notified of new items in a subscribed stream. See the runtime parameters page for more information: https://www.multichain.com/developers/runtime-parameters/

In terms of redundancy, from MultiChain's perspective there's no problem with two nodes attempting to complete the exchange at the same time, because each exchange can only be completed once, and the chain will automatically reject the other (conflicting) transaction.

However this can of course be a problem if you're doing something external to the chain (such as debiting a credit card) as part of the process. This aspect of this issue isn't actually related to the blockchain, so you would need to employ a standard mechanism for redundancy/failover. Or perhaps you can include some kind of ID (hash of the exchange offer?) with the instructions to the credit card system, and request that they prevent processing duplicate transactions in terms of that ID on their end.