A while back I started working at an IT department that didn’t really have much in-house development, and thus didn’t have any integration architecture defined. I set out to look into our business needs along with potential architectures.

I’d been a great fan of message based, event driven architecture, and found that to be a good fit for our needs. One of my first projects was quite simple – the user would visit one of our internal websites and submit a form. On the backend, the form data would be processed by a service.

From the user’s standpoint, it wasn’t really important if the form data was processed immediately or not, as long as it was processed within an acceptable time frame. In other words, a sort of eventual consistency, as opposed to transaction based, flow would, from the user’s standpoint, be sufficient.

I decided to implement this workflow:

A short walkthough:

1. The user submits the web form, and the data is passed to a REST API endpoint on the “http-to-mq” service.
2. The “http-to-mq” service basically takes the HTTP POST payload data, inserts it into an MQ message, and publishes the MQ message to an exchange on our MQ server.
3. After successful MQ message publishing, the “http-to-mq” server responds with a HTTP 200 back to the client. The user then gets a conformation dialog indicating that the form submission was successful.
4. The Service A, which subscribes to these types of messages, consumes the message and performs our business process.

Note that both the MQ exchanges and the MQ messages are tagged durable, so even if something happens to the MQ server during processing, the message is not lost. So as soon as the “http-to-mq” service gets a confirmation from the MQ server that the MQ message have been published successfully, I know that the MQ message won’t get lost even if the MQ server somehow crashes, or if the service A crashes.

Designing the architecture this way may seem somewhat overkill, as one could argue that the web form could simply post data directly to service A. For us however, it was more important to base our internal integrations on message based, event driven architecture, so that any synchronous events such as a user or external partner posting data to us was acknowledged and “converted” to messages on the outer borders of our domain. This way, the user or external partner won’t get errors thrown at them if something goes wrong in our internal systems, as long as the “http-to-mq” service is up and able to publish messages to the MQ server. If anything goes wrong downstream from that point, we’ll probably fix the issue before the user or external partner even notice anything have happened.

Just thought I’d share this info, in case others may benefit from it. I was looking for this type of information myself when planning our architecture, so maybe the post may be of help for others in the same kind of situation.