1

I have a system that uses mongoDB as persistence and RabbitMQ as Message broker. I have a challenge that I only want to implement transactional outbox for RabbitMQ publish fail scenarios. I'm not sure is it possible because, I also have consumers that is using same mongoDB persistence so when I'm writing a code that covers transactional outbox for RabbitMQ publish fail scenarios, published messages reaching consumers before mongoDB commitTransaction so my consumer couldn't find the message in mongoDB because of latency.

My code is something like below;

1- start session transaction

2- insert into document with session (so it doesn't persist until I call commit)

3- publish rabbitMQ

4- if success commitTransaction

5- if error insert into outbox document with session than commitTransaction

6- if something went wrong on mongoDB abortTransaction (if published succeed and mongoDB failed, my consumers first check for mongoDB existence and if it doesn't exist don't do anything.)

So the problem is in here messages reaching consumer earlier than mongoDB persistence, do you advice any solution that covers my problem?

sercanD
  • 187
  • 1
  • 13

2 Answers2

0

As far as I can tell the architecture outlined in the picture in https://microservices.io/patterns/data/transactional-outbox.html maps directly to MongoDB change streams:

  • keep the transaction around 1
  • insert into the outbox table in the transaction
  • setup message relay process which requests a change stream on the outbox table and for every inserted document publishes a message to the message broker

The publication to message broker can be retried and the change stream reads can also be retried in case of any errors. You need to track resume tokens correctly, see e.g. https://docs.mongodb.com/ruby-driver/master/reference/change-streams/#resuming-a-change-stream.

Limitations of this approach:

  • only one message relay process, no scalability and no redundancy - if it dies you won't get notifications until it comes back

Your proposed solution has a different set of issues, for example by publishing notifications before committing you open yourself up to the possibility of the notification processor not being able to find the document it got out of the message broker as you said.

D. SM
  • 13,584
  • 3
  • 12
  • 21
0

So I would like to share my solution.

Unfortunately it's not possible to implement transactional outbox pattern for only fail scenarios.

What I decided is, create an architecture around High Availability so;

MongoDB as High Available persistence and RabbitMQ as High Available message broker.

I removed all session transactions that I coded before and implemented immediate write and publish.

In worst case scenario:

1- insert into document (success)

2- rabbitmq publish (failed)

3- insert into outbox (failed)

What will I have is, unpublished documents in my mongo. Even in worst case scenario I could re publish messages from MongoDB with another application but I'll not write that application until I'll face with that case because we can not cover every fail scenarios on our code. So our message brokers or persistences must be high available.

sercanD
  • 187
  • 1
  • 13