1

I have a service A which does the following:

  • Create/Update a Person and publish a create/update event.
  • Also save the Person job data in service B's database.

Service B upon saving/updating the data in it's DB, triggers its own create/update event.

Now I am receiving these 2 RabbitMQ events from service A and B in another service C. I have a requirement where I need to make sure that I receive event from service A first and then update a field in that event's data by extracting that data from the event of service B. I have following questions.

  1. Can I assume that as A is producing event before B, in my service C I will always receive A first and then B ?

  2. If not, how can I guarantee that I will always have event of service A before B ?

While doing some initial testing, I can see that I am receiving A first and then B with a difference of like 0.0001 seconds (which is fine). But this seems to be a happy path.

Any help would be appreciated.

newLearner
  • 637
  • 1
  • 12
  • 20
  • Since you did not say which framework or library you are using but regardless you can send the DB version in your message. Upon receiving message if the version is not latest that match with message then you can reject requeue message with right info. There might be other ways too. – nicholasnet Nov 10 '20 at 11:38

2 Answers2

0
  1. No.
  2. No way.

The only way to fix it is to mark messages with some unique ID, so that messages from A and B have the same ID, and wait for both messages.

Alexei Kaigorodov
  • 13,189
  • 1
  • 21
  • 38
0

This answer might help guide you here: RabbitMQ - Message order of delivery

From that answer they say "With multiple (parallel) consumers, order of processing cannot be guaranteed."

If the message from "Service A" has a unique identifier and is included in the message from "Service B" then maybe one thing you could do in "Service C" is when you pick up an message from "Service B", check to see if you have received the unique identifier from "Service A". If not, then you could send a NACK back which will re-queue the message until you can process it fully. But that could get messy.

Ocean Airdrop
  • 2,793
  • 1
  • 26
  • 31