Proper use of microservices within the system

Question

I have an application in which a client interacts with a backend, which interacts with blockchain. Since blockchain executions can be time-consuming, they are executed asynchronously within different services. I have one shared database. There are total of 3 services.

1. Rest API service: this layer serves all the requests coming from the client. Saves to and reads from the database, both data and blockchain transactions to be submitted by the executor.
2. Blockchain Transaction Executor: reads submitted transactions from the database every 2 minutes and sends them to blockchain, and then marks the transaction in database as submitted. The reason I am using database and not a message queue for such task is simply because I have batch execution functions on my smart contract, thus I need to batch and format all the transactions at once. PS: This service does not wait for transaction to be mined, but only for it to be submitted.
3. Chain Listener: listens the smart contract for mining of the transactions and captures events emitted, and updates the database status of the transaction to success.

My question is simple: Can I somehow benefit microservices to make this system more independent?

In my opinion the bottleneck is the shared database, if somehow Transaction Executor and Chain Listener can be made unaware of the database, it will be a much better system. But then if its done other problems arise as well. We have to have another service to watch (through event queues or smh.) what those 2 services emitted and then update the database accordingly which I don't feel like its a proper solution. Because then still the database is shared, and also I can't even name such a service (database-syncer?) because I don't know what its gonna do exactly, I am afraid it could turn into a garbage collector. And how am I gonna apply batching on Transaction Executor etc.

I would like to know whether I can do to make this system more decoupled, and whether I should even try to. Because I am not sure whether the overhead of abstraction will tackle its benefits for this system.

Answer 1

I guess you have figured out the right problem that shared database is bottle neck. I would suggest to move to database per serivce pattern. Start using kafka to make your system more decoupled. You can use kafka consumer to sysnc data between your different serivces instead of adding another service for this serivce. But you have to take this step after looking into the scale pattern of your system. If you think your system will scale with time and you will have increase in traffic with the passage of time than this is right approach to go for. Otherwise shared db is fine I guess until you have constant traffic and are not expeting in growth in usage.