1

I am learning a microservice architecture and have created 3 microservices. Each ms has its own database.

Something like below,

  1. Business ms
  2. Customer ms
  3. Tax ms

enter image description here

I designed it in the way by duplicating the Business table in all microservices. Whenever a new business is created in the Business ms, I wanted to update the business Id and the name in the Customers ms and the Tax ms to create a reference.

I tried to achieve this in the below way,

  1. Hosted Service - This will be registered as part of the Business microservice and when a new row is added in the business table, I am adding that row to the System.Threading.Channels. HostedService will read the queue and then call Customers ms and the Tax ms API to update the Business Id and the Name.

  2. Event-Driven API - I've not achieved this yet. Idea is to have Business ms as the producer and Customer ms and the tax ms as the consumers.

What is the best approach to achieve this? Any ideas on this, please?

Hary
  • 5,690
  • 7
  • 42
  • 79
  • 1
    My preferred method would be for Business service to publish an event to a queue on create/edit/delete, any other service that cares subscribes to that event and processes on receipt. Clean, set-and-forget, and extensible to any future services requiring the same. – meshtron Jul 19 '21 at 20:04
  • In that case, If we need the status back? Does the consumer have to send a message back to publisher stating the success? Is that the followed way? – Hary Jul 20 '21 at 06:40

1 Answers1

3

We have the same requirement as you mentioned, We adopted the event-driven architecture to solve this issue.

Apache Kafka is the best messaging system to use for such requirements.

Few things you need to consider while implementation.

  1. Suppose CRUD microservices(Which interact with DB and persist the main entity) saved the data to DB and Kafka server(any messaging system) is down, then it will inconsistency of data. Solution to this problem is, You need to create the new table which keeps the track of the event which were failed while publishing. In background, the corn job will fetch all failed events and try to publish again.

  2. You successfully published the event on-topic but the consumer is down. In this case you don't need to do anything because once the consumer is up, it will start reading the message.(Note consider the retention period of message)

  3. You successfully published the event on topic and the consumer is up and running, but because of the data format issue, the message was not getting consumed, then this case again data inconsistency happen between microservices. In this case, need to push that event data to DLQ and need to parse it again.

Vaibs
  • 1,546
  • 9
  • 31