Microservices loose coupling using distributed business logic or centralized?

Question

How do we achieve loose coupling in the below scenario:

N microservices (let's call them Callers) needs a logic or business( let's call it Worker) to be executed with different contracts. Although the contract is different, logic is almost identical and work on data stored centralized in a DB Worker is likely to evolve a little bit in respect to each caller microservice.

Also, I would like to add that Worker will always have the same data to work with.

So, I am thinking about below options to consider :

1. Do we have logic(business) added to all the Caller microservices which may have minor logic changes and get the data from the microservice which maintains the data?
2. Do I create multiple endpoints (have a separate contract) from a single microservice with centralized logic for the Worker and maintains the data?
3. Have single endpoint and have merged multiple microservices contract and with centralized logic for the worker and maintains the data?

Also, what type of communication will fit Kafka vs Rest and in what scenario?

Answer 1

Here is a resume of what you said from my understanding (please validate):

• You have N microservices, where N ~= 10 (could grow). Let's call them consumers
• Each microservice will require data
• The data required is stored 1 database
• Each microservice requires this data differently

In order to support these requirements, you propose that a specific microservice will manage the data required by the consumers. Moreover, this new producer will keep business logic that is required for the consumers.

Before answering the 3 questions, just remember that a microservice can be decoupled so much that it becomes an anti-microservice. For example, creating a new application with a specific technology stack just to maintain the name of a user where another one will maintain personal information is not ideal. So instead of seeing your problem from a technical perspective, incorporate the business aspect of it.

1. Do we have logic(business) added to all the Caller microservices which may have minor logic changes and get the data from the microservice which maintains the data?

   • If the business logic is specific to the callers, it should stay in the callers and let the worker only provide you the information in the database.

2. Do I create multiple endpoints (have a separate contract) from a single microservice with centralized logic for the Worker and maintains the data?

   • If you want to use a microservice architecture, this data has to be maintained by only one microservice, the worker. Who ever wants the data (and can edit it) should request it from the worker. The multiple endpoints would be the different contracts required by other services or possible humans. i.e. Getting a list of the available data, deleting some data, updating data.

3. Have single endpoint and have merged multiple microservices contract and with centralized logic for the worker and maintains the data?

   • This really depends on what the callers need. If for every new caller, you reuse the same endpoint from the worker and add new logic in the worker, you might break compatibility between the other callers and the worker. This works if you don't need logic for the endpoint and it is purely sending information and the callers apply their own logic to the data.

All in all, revisit what is exactly the business logic you need per caller. If only the worker can apply this logic, then use different endpoints (contracts). If the logic is inherent to the callers, then move the logic to the callers and keep the endpoint as simple as possible. Consequently, that endpoint can be reused until a new caller needs a new API from the worker.

REST vs Kafka

As for your last question, consider these:

• Kafka is a technology using a publisher-subscriber pattern
• REST is an architecture that you can use to represent data in time

I would say use the publisher subscriber pattern only if you need your application to notify and/or be notified of something. In your case, if your callers uses Kafka, they will basically be waiting for update notifications on the data from the worker. That also means they have to persist the data on their side. If both callers and worker are in the same system, this is unnecessary complexity (if you only want to read data from a database).