I would like to create a system which handles alert messages from various programs and can process those alerts to down-wind consumers via email. This would all be contained over one internal network.
I think I want the basic architecture to look something like this:
The main concern I have currently is the "Message Handler" bit, which is what will be my "sort-of-API". I want all components of this system to send data to the API, which handles all writes to the database. I think this approach is easier because it simplifies security, and allows me to contain a lot of the more complicated DB queries into one single program.
The concern is that I want this to be language agnostic – meaning that any code should be able to send messages to my Handler – which will interpret them. I hope to do this via JSON flat files – or via REST calls to the program (giving flexibility to the down-stream applications).
My question is-
Should I bother with the message handler – or would it add simplicity to just allow direct database access to the down-stream applications, as well as the two other components (Management Console, and Alert Manager)?
That way, they can insert whatever alert they would like – as long as the INSERT into the DB table/s is valid.
I'm not a software designer by trade so excuse me – I just want a project to do in my free time.
Best Answer
Have you looked into AMQP (Advanced Message Queuing Protocol: https://www.rabbitmq.com/protocol.html)?
RabbitMQ is an awesome tool for something like this, I think (there's others as well, MSMQ, Azure/AWS services, etc.). Not only do you get one language agnostic message handler (simple "send the message to the message server w/ json data"), you detach the downstream message processing and make it well isolated. Run a message service that processes incoming messages from the queue(s) you need and spit out your notifications.
One of the reasons I really like using AMQP is that you start off like you are now with some home-baked solution, but realize after time you need to handle messages slightly differently depending on the type, who it needs to go to, etc., so you end up essentially building your own AMQP implementation anyway.
What do you do if a message needs to go to 5 different recipients? What if you have a message that should be rotated throughout a number of processors (think long running tasks and having X number of simultaneous processors, where you can round-robin messages of a specific type). What if the message should go to one person, but if they're not available/online, it should go to another? The AMQP handles all of this (quite nicely!) already, with very nice categorization, queues, channels, durable persistence, all sorts of features.
Here's a basic overview of the scenarios it can handle (note this is not specific to RabbitMQ: it's an AMQP thing, but RabbitMQ happens to explain it well) - https://www.rabbitmq.com/getstarted.html