MessageBus pattern to do an initial sync

Question

I have two (micro)services A and B where service B is interested in data of service A. Let's say service A has a table of products with a lot of fields. Service B wants to store a table of products with a subset of the fields (name and id).

To keep service B up to date, my intention is that service A will send messages to the message bus for create / update / delete of products. This seems to be a common approach.

But now there is the problem of an initial sync (or maybe once a resync), because service B is a new service and service A already exists. I do not find any best practice on that matter. I can imagine two solutions:

Solution 1: Service B pulls the initial data via the additional REST API which service A also offers. Disadvantages i see, is that i need to configure the URL and as well service A has to be running at the moment, so i would not prefer this solution.

Solution 2: Service B sends a message with the intention "SyncProductRequest". Then service A sends for each product an update or sends all product at once in one message. Sending all at once probably is not a good idea because of the message size. On the other hand that way i could easily remove products which are not existent anymore in service A. As well i see the problem that it could occur a situation where one product is changed at the same time as sync is happening. This problem i think i could only solve by having a modified date time on the product.

Would you solve this "initial sync problem" with solution 2 as i described, or do you know kind of a best practice for this type of microservice problem?

In case it matters, i am using; .net and masstransit with rabbitmq

Answer 1

What makes sense is the way you are describing by sending some SyncProductRequest. Your service A can listen to that message and start dispatching Inserted/Deleted/ProductEvent (same event as for "normal" events). You might add some additional property that this is a synchronisation response so that other microservices don't create unnecessary load and can filter those messages.

I would stick only to event messaging (rather adding rest) because you can keep your implementation for the same purpose of consuming insert events.

Be aware that there might be race conditions between insert/deletes depending on your message infrastructure and ordering guarantees.