-1

I know that this question has been discussed a lot already, but I would like to describe my situation.

As far as I know, there are techniques and best practices to solve the shared database in microservices architectures (event sourcing, CQRS...) but all of that seems to complex for my case, let me explain.

I built a rest API using nodejs. This API allow you to fetch, using a GET request, the data stored in a mysql database. Now I need to import a lot of data in the same database (creating every time a new table). The first solution could be to add a new endpoint (POST request) to the existing microservice to create the new table and add the new data.

But I was thinking about to create a different nodejs microservice (import service) because the import feature could be very CPU time consuming and nodejs is single thread; I don’t want that a user has to wait to fetch the data because another one is importing the new one.

The problem whit that solution is that I have to share the same database between the 2 microservices. Using the typical approaches (event sourcing, CQRS) could be the best solution but it complexs too much the architecture ( for this project I don't need to address the data consistency problem).

There are others 2 solution that I can use:

  1. create a common Lib to access the DB and use the lib in the microservices
  2. The “import microservice” instead of access to the database directly, can use the API rest of the other service to post the new data as soon as they are ready to be imported.

What is the best solution? Do you know other possible ways to address this problem?

Thank you very much

Robert Moskal
  • 21,737
  • 8
  • 62
  • 86
Fabry
  • 1,498
  • 4
  • 23
  • 47
  • 1
    You may get shut down for this being too general or a matter of opinion, but I don't see what event sourcing or CQRS have to do with this use case. Both 1 and 2 of your other solutions would work and I'd say it all depends. I would ask my question in terms of those two alternatives, with your listing out some of the pluses and minuses. – Robert Moskal Nov 17 '17 at 18:33
  • I tried solution 1 in Micronaut but I get multiple dependency error. https://stackoverflow.com/questions/71665667/shared-microservice-micronaut-error-multiple-possible-bean-candidates-found Were you able to solve your problem? – Ishika Jain Mar 30 '22 at 02:27

1 Answers1

1

In the microservices world, services should be divided according to the bussiness domain that each service represents and not by specific technical functionality as you are proposing. This is an architectural design that I don't recommend bypassing just to workaround some specific technical funtionality.

The approach to solve your problem is not by splitting the microservice into two services that are in the same business domain.

Your problem is a performance issue. Performance issues are generally solved by scaling. It is totally normal to replicate your serivices by deploying multiple containers. Docker gives you this option by default where when deploying a service, you can specify the number of replicas to deploy.

yamenk
  • 46,736
  • 10
  • 93
  • 87