Bdtjtk

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?

In order to be able to scale each functionality by itself, it is good practice that you separate the background jobs from the exposed APIs. If you don't, you may for example have much more resources allocated to the background jobs that you need because you needed to scale the APIs.

It is the ubiquitous language that makes those objects explicit in every subdomain, and it is this language that defines the bounded_context/microservice boundary and so its size. My point is that an object representing an actor that triggers emails to customers given a certain condition is identified within the customer subdomain and so it is where it should belong. And the same concepts applies for the crons you of your Catalog subdomain.
Other than that, you must have an Emailing library (shared kernel) in a commons project that could be used by every subdomain, but this library should know nothing about emails content. Content is specific for each subdomain (customers MS send promo email using this commons library). Same for jobs, you could have a crons library in your commons project used as a dependency from all your MSs, but you should define/specialize specific business jobs in each subdomain.

I'm assuming that the same code base/repo holds the code for both the API and the background process - that is why it is convenient to deploy both together and having both share the same database.

There should be a good reason to separate the code base, or the database they use. here are some good reasons:

• If you roll out changes in one more frequently


• they need separate views in the database


• they have different requirements of database availability

Scaling is not a good reason to divide the repos or the database, in my opinion and will only cause duplicity of code and opens a breach for data inconsistency and bugs. Scaling can be done by adding more processes of one vs the other -

You haven't mentioned how you are deploying, but an example could be having different kubernetes deployments with different replica sets and scale, but have the same docker image, that has two different entrypoints.