CODEWITHSUNDEEP
databasearchitecturerabbitmqmessage-queuemiddleware
Mik378
Mik378

Reputation: 22191

Should I need a database to ensure immediate consistency with a message-oriented middleware?

App A wants to send domain events to App B through a middleware like RabbitMQ.
Let's take the example of one domain event called UserHasBeenRegistered, involving by the creation of the User entity.
A would inform B that this latter should send a welcome email, by sending this event.

I have in mind two workflows:

First:
- App A registers the user and the event is generated.
- App A sends the event directly to B through a queue provided by RabbitMQ

Second:
- App A registers the user and the event is generated.
- App A saves the event in some kind of event store as a database table (if relational) in the same local transaction used for persisting in database this new user.
- An asynchronous scheduler queries the event store, find this new user registration and sends the message through the RabbitMQ's queue.

Do you see the difference?
Yes, one is longer than the other... but the second is far more safe! albeit less performant.

Indeed, what while in the first case, the registration is rollback due to an exception thrown just after the publishing was made? => the mail would be sent whereas the user was not persisted.

This could be fixed by implementing a global XA transaction (two-phases commit), but it is well known that some middleware don't support it.

Therefore, is the second workflow mostly used in critical application?
What are its drawbacks?

I plan to implement one of both solutions for my project.

Upvotes: 1

Views: 157

Answers (1)

pinepain
pinepain

Reputation: 12879

I had the same task and it was done as a mix of your two workflows:

  • App A registers the user and the event is generated.
  • App A sends the event which has ttl set to non-zero value directly to B through a queue provided by RabbitMQ.
  • App B receive event and send welcome message to user and store flag that welcome message sent.
  • There are background script which check whether there are newly registered users from last ttl + 1 time interval who doesn't receive messages.

You can remove background script and flag storing and stick with first workflow from you q. The cases when messages lost or any other cases are damn rare (with welcome messages sending it might be 1 failure per 1billion users) and unnecessary application complication may give you more errors.

The second workflow looks also stable, but why you are using RabbitMQ then?

Upvotes: 1

Related Questions