2

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?

  • How big is N? Is n < 5 or n > 1000? How important is it that the various callers are unaware of other options? If the callers need to have some sort of privacy wrt to call options, (that is 'Oh, you I can get "X" with this call?' would be a bad thing), then different multiple end points routed through different aut levels may be the best. Other wise, fewer endpoints with a more expressive call request object may be fine. But without knowing about ||N|| or a privacy/information hiding requirements it is hard to make a choice. – Kristian H Aug 19 '18 at 18:08
  • N will possibly be around 10 and no problem privacy in our system as its internal system. – Vishal nigam Aug 20 '18 at 4:31
  • Will the worker be acting like a resource manager (single point for reading and editing the data)? – gumol Aug 20 '18 at 14:53
  • @gumol Yes, it can manipulate data and master data needed to apply some rule on data are rendered in DB and common for all the Caller microservices. – Vishal nigam Aug 21 '18 at 6:45
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).

  • The worker has both business logic and data. It's just that we foresee that we may see some additional business logic on Caller basis. For the same reason, I am having some doubts to keep logic on worker end would mean that even minor change in business will a lot of time and increased testing and deployment issues. Thank you @Gumol for the reply. – Vishal nigam Aug 22 '18 at 18:48
  • No problem! Your forecast is right. Make sure that the logic is in the right place by asking yourself some questions, otherwise expect worker to become Codezilla. – gumol Aug 22 '18 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.