I have a large customer facing web applicaton (.net mvc if that matters) that I need to split down to a number of services. Some of these services will then be shared with other applications.
At the moment all of the servers I have are part of a web cluster that we use for this app, though this may change in the future.
What I am struggling with is deciding between learning a Message Queueing system such as RabbitMQ, which should improve performance, and will run over tcp/ip, making it possbile to take some of these key services away from the web server cluster, and carrying on with creating an internal JSON / REST API. (Which we are already familiar with, but will not help improve performance.)
However, being as RabbitMQ Queues are one way, I would then need to come up with a strategy for handling occasions when the website / user needs feedback from one of the services. Which means some way of creating a session specific return message queue, or relying on RPC, which may then impact on performance.
To my mind RabbitMQ gives me more flexibility and opportunity (I can move code off web servers, manage message queues and so on), but also creates more risk as its unknown to the business, and means that not only are we splitting our application up, but we are adding in a new communication method.
So, has anyone implemented RabbitMQ in a web based scenario like this, and if so, do they now regret it, and wish they had stuck to using REST? (Or vice versa)