Multithreading message broker in a transactional system - Best Practice [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

We have 2 systems that exchange tickets base on a transactional flow, they have an order in the ticket statuses if one status does not reach one system all the flow is stuck. The problem is that we use a multi threaded, load balanced message broker between this systems and we might have cases when an update1 status can be processed faster than a create, or update2 faster than update1.

I'm look for a best practice for this kind of integration.

Answer 1

Your issue really is that you have a message brokering application that your application communicates with asynchronously, however your technical requirements are such that messages must be processed in a synchronous order.

Depending on what software package you are using as your Message Broker, many such products will have built in features for message delivery to recipients based on an appropriate sequence order. This is a subject of debate, but I feel that using or relying on such a feature in a message brokering application is a sign of a "design smell".

What do I mean when I say "design smell", well basically it is a feature provided to you in this tool that helps hide the fact that your application logic cannot handle such scenarios where messages are received out of order. You have clear user requirements that these messages must be processed in a certain order however you are relying not on the code of your application to ensure this but on a feature of a tool that now is tightly coupled to the proper functioning of your application. I am not saying that this feature of your message brokering tool is a bad thing altogether though, it can be incredibly useful for ensuring that the recipient end of a message broker receives messages in the proper order if the recipient application is a more brittle vendor product or older legacy product to where you do not have the time or capacity to improve the design of said application.

So if you agree with my assessment that using such a feature in a message brokering tool introduces tight coupling to your application, OR if you simply have no control to change or affect your message broker tool, then one way I have seen this handled is to build a staging area in your database for messages to be received in. This need not be a normalized relational database structure, the important point is that you receive messages from your broker, persist them into a staging area and designate the proper processing sequence at this time. In a separate application thread or scheduled task you can routinely check the staging tables for messages eligible to be processed by your application.

The important point to remember is that your application as the recipient does not ACTUALLY REQUIRE messages to be received in proper order, it requires them to be PROCESSED in proper order. Furthermore the responsibility of the message broker is NOT to guarantee to the sending system that the receiving system has successfully processed the message. The message broker's only responsibility here is to guarantee that the message was successfully delivered to the recipient application(s) and that they returned an Acknowledgement message stating that they received it and will ATTEMPT to process it.