We have a JMS based messaging application which handles around 2 million messages per day.
Now we have an additional feature to be launched which affects 60% of the total messages i.e. 1.2 million messages per day.
The plan is to have an internal queue on which we will forward the messages for this additional feature
The 2 design options thought of so far are:
a) Forward all messages to the 2nd queue on which a message driven bean (MDB) will process them – this isolates the first application from knowing whether or not this feature is required at all.
b) In the original application, filter out only the 60% volumes and forward them to the necessary queue – and thus reduce unnecessary traffic internally
So essentially balancing design vs volumes – which way shuld we go?
Option B. might give you a headace in the future. Keeping such filtering logic inside two business applications is rarely a good idea – think about changes to the filtering rules in the future that will trigger new versions of two applications.
1.2M msgs/day is quite a number, if the messages are not tiny. Your solution A) is the easiest to build and handle of time, if the systems can cope with the volumes. I would do some load testing and if everythings is fine, go ahead with b).
Depending on which plattform you are building on etc. many middleware and messaging products offers logic and filtering features that can be applied in the middleware, rather than in the actual application.
For instance, this could easily be configured via Apache Camel in a few lines of XML.