I am getting involved with a project that will build, at first, a simple message system that will receive messages, store them and route them to appropriate departments. The basic use case is:
- Person writes a message or a question in a website form and chooses a department to route the message to
- Based on the person's selection, the message gets routed to the proper department's message queue with a status of "unread," "read," etc. (we don't have all of the statuses determined yet).
- These messages become part of a person's interaction with the website, i.e., if they call customer service, they will be able to pull up the messages that person has sent and received
The basic question is whether or not a message broker is justifiable in this scenario. I can see arguments for and against. First, simply writing messages to the database risks timeouts, deadlocks and such that could lose messages. Code would need to take care of these scenarios. A message broker, such as RabbitMQ, could process messages and save them regardless of whether the databases or systems are up and running and so lessen message loss.
On the other hand, a message broker also seems like overkill because it's simply passing messages to one or more departments and then disappearing into a person's history. So why include all of that infrastructure for something so simple?
This system will get built upon from this initial framework, so it won't remain a simple message sender, but as of now it will not connect applications or systems together nor does it seem to be providing anything like ESB functionality. Right now, the plan is to use RabbitMQ, MassTransit and Sagas to send, route and track messages. Is this too much? Or is it warranted since we aim for a 0% failure rate?
Thank you!
