Home > Net >  Prevent parallel executions of scaled ASP.NET Core hosted service
Prevent parallel executions of scaled ASP.NET Core hosted service

Time:06-03

I have web api hosted on AWS (AWS fargate). I want to make sending some emails and other stuff as Background service. Problem is that in case I decide my web api to scale that multiple instances of that hosted service will be executed.

I have sql database and some table where "IsEmailSent" and "IsReportSent" flag exist.

Background hosted service just loops through all rows where that fields are false so implmenetation of that service could be relatively easy.

However, when it comes to "preventing" multiple instances run hosted service there are couple of options. What would be most easy way in this kind of setup? This is what to my mind first:

Introducing some kind of database locking which could be dangerous and not too performant.

Using AWS SQS and dequeuing inside background service is option but would like to avoid it if not needed since I currently don't use SQS anywhere in app.

CodePudding user response:

To manage multiple instances to not get the same item you need a "push" system. The optimum way to implement that is via queue.

If you don't want to use a queue, the other way is to control the instances, and "start" the worker in only one instance. You can use a simple database to select wich instance is available to work on items.

But I repeat, the best way to do it is via Queue or via Hooks

CodePudding user response:

I have several idea how you can solve this promblem.

The first one, try to make master service the one of your multiscaled services. It is the only one service who can handle commands and where you can start the backround service for e-mail sending. Other services will handles only queries(GET methods). To achieve this you can use configuration file. And run master and slaves with different configuration. You can find another way that is more according your infrastructure. The goal is run only one background service. This don't preffer this way.

The second one require to indroduce an additional service. It can be also .NET app with running background service, but it must do nothing else from reading DB and sending e-mail. You run this application as one instance. It haven't to be scaled. Also you can use WebHook to decouple this service from database. It allows you subscribe to some events and send e-mails without accessing DB of another service. If you wanna scale e-mail sender service can solve it by load balancer or you should look at event bus(if you already use it in your stack it is good choice). This I would preffer more then the first one.

  • Related