[rabbitmq-discuss] Architecture Question: 2 Brokers, or Not 2 Brokers ?

[dnsplus]

Jerry Kuch wrote:
> 
> Hi, dnsplus:
> 
> Could you perhaps clarify a bit what you mean by "remote?"  Are you
> talking about systems that are geographically separated from your
> "central broker" for some reason external to your application?  Or
> are you just talking about having 8,000 consumers?  The latter
> shouldn't be a daunting number at all for even fairly modest Rabbit
> deployments.
> 
> Best regards,
> Jerry
> 
> 

Its a little complicated, but I'll give it my best shot:

Jerry, for you ... Definition of a Site:  A retail store location, from 1 to
~1800 miles away from the data center where the Central Broker runs). 

I am working with a large environment which has no guarantee of a stable
network, or guaranteed bandwidth to the remote sites. The typical CIR is
384Kbps, with a 1.544Mbps MAX (yep, fractional T1s). To mitigate the
possibility that network connectivity to a site, or region, can be
unavailable for an undetermined period of time, at any time, and for any
reason ... we think guaranteed message delivery with RabbitMQ is the
foundation we need for this 'application' to work. 

The message payload for this application will be well formatted XML which
contains instructions that will be parsed, interpreted, and executed via a
consumer at each client site, implemented in PERL. 

So ... should I be using a Central Broker, which forwards a message to a
queue at a remote broker, which is consumed by the client process?

Or, do I leverage the Central Broker with a Queue for each remote site, and
configure the consumers to talk to the Central Broker for message collection
and processing.