Avoid Single Point of Failures by Introducing Multiple Master Backup Reader Node on Steem Bot Applications

Previously, I have integrated the ChatGPT AI Bot to the Steem Blockchain: Integrating ChatGPT Prompt AI to STEEM blockchain and I have shown you the System Design of a Bot (dApp aka Distributed Application) that is running on the Steem Blockchain.

There is one problem. There is a single point of failure when the process (reader) that listens to the operations (in particular, the comments/posts) may crash and a record may be missed as the reader will not scan back the history operations on the blockchain. However, this reader can be duplicated and spawned on other servers as many time as possible. We just have to point them to a single database which we will add the unique record constraints:

1	alter table blockchain add unique key (block, ...);

alter table blockchain add unique key (block, ...);

Then each reader process becomes stateless, and the Database constraint ensures that only 1 record will be inserted into database, all other readers will fail with “Duplicate key exists” error, which is fine. The database serves as a message queue, and the “Reader” process is the producer, and other applications/bots are the consumers, which will pick relevant record, process, and then enqueue to the comments table (or other actions). Other components are less subjective to Single Point of Failure because they are running in the container, which can be restarted and re-process the un-processed records on any failures such as crash.

The multiple readers are all master nodes (Master to Master), and they are stateless, so they don’t need to exchange information. Their job is to read transactions on the blockchain and put them in a same table. So it is unlikely that the transactions will be missed if the Databases are reliable.