We have a microservices architecture very similar to the architecture described here
Obviously, it's a simplified diagram of a real system. In our case, we have a requirement to perform background operations in a service in addition to exposing APIs. e.g.
- In the Catalog service, if a certain product's count goes below a threshold, a notification needs to be sent to fulfillment team
- In the Customer service, if a customer has not logged in for x days (and opted for promos), a promo email needs to be sent
Now my question is: should these background jobs be their own microservices (with own executable and own database) or will be another executable in the same microservice? For example with the latter approach, Customer service will comprise of CustomerAPI and CustomerPromoJob and share the same database. Is that an anti-pattern as all the applications in the Customer service will have to be deployed at the same time?
Best Answer
It's a fairly common need to have background processes that work against a single micro-service sized chunk of data alongside an API - especially in environments that use data buses or message queues to buffer things that can be eventually consistent. And it can be desirable to host them alongside the actual API so there's less chance of partial deployment failure.
That said, they need to be cohesive enough that your microservices are still focused on a single responsibility with a tiny data scope. And running them all together can cause performance, monitoring, security, and operations trouble.
So as with most things, it depends. There are tradeoffs for either approach, and you should maybe err towards keeping them as separate services, but there are common scenarios where it is good to bundle them.