You'd host the queue service on a separate machine on the private network and communicate with it using either HTTP or standard TCP (all firewalled to restrict everything else)
So you have your gateway virtual machine which has one interface to the public web and one interface to the internal network. On that network you have two or more machines:
a) is the web server, which can't make any requests out to anywhere except other machines on the same local network. It can receive tor or http traffic in from the gateway
b) other servers hosting local services, which can't make any requests out at all but can receive queries from the web server on their http/queue port. A database server for your web application would also sit on a machine like this.
You can put b) on yet another separate network behind the web server if they don't need to route out over Tor (or even if they do).
Your slicing the tasks up and isolating them on separate machines to minimize the attack surface. Someone breaking into the web server will not be able to make any queries out to the web or to tor, and will only be able to query local services servers in b) such as the queue.
RabbitMQ has an HTTP interface, 0MQ uses TCP.
The other way to do it is to isolate every machine from every other machine and implement a SOA over Tor.
Taking the example of your web server needing to know the latest bitcoin price, you would implement an API on another hidden service and restrict access to it from only your web server. The web server would then have to be allowed to make queries out over Tor, but this can remain on the Tor network and can again be restricted to only your hidden 'proxy' services.
Most people associate Tor and hidden services with sites being slow and down all the time, but that is more a function of the level of experience in the field. Tor hidden sites have a different threat model so the ideal architecture is different to most common network architectures.