Hi All,

I'm new to RabbitMQ and AMQP, and I'd like to see what people with more experience have to say about exchange & queue design. I'm experimenting with using RabbitMQ to replace a homegrown thrift-based messaging solution that is used to relay change notifications from 10 or so CouchDB databases to several hundred running instances of our application.

My first thought was to create an exchange for each observed database observed, each exchange named after the database (i.e., couchdb_changes.db1 ... couchdb_changes.db10). A routing key would be set for messages based on the value of some field in the database document. Each client application session would then create and bind a queue to each of the exchanges.

My second thought was that I could create a single exchange named "couchdb_changes", and then add the database name to the routing key. When binding queues to the exchange the application would also incorporate the database name into the routing key.

So, are there advantages or disadvantages between the two approaches here, or are they largely functionally equivalent. I prefer the feel an exchange per observed database; just curious if there are established patterns that I should know about to better inform design decisions.

Thanks!

Mike Beam

Search Discussions

  • Matthias Radestock at May 15, 2011 at 6:43 pm
    Michael,

    apologies for the delay in getting back to you...

    Michael Beam wrote:
    I'm new to RabbitMQ and AMQP, and I'd like to see what people with
    more experience have to say about exchange & queue design. I'm
    experimenting with using RabbitMQ to replace a homegrown thrift-based
    messaging solution that is used to relay change notifications from 10
    or so CouchDB databases to several hundred running instances of our
    application.
    Interesting. Distribution of DB change notifications seems to be an
    increasingly popular RabbitMQ application.
    My first thought was to create an exchange for each observed database
    observed, each exchange named after the database (i.e.,
    couchdb_changes.db1 ... couchdb_changes.db10). A routing key would
    be set for messages based on the value of some field in the database
    document. Each client application session would then create and bind
    a queue to each of the exchanges.

    My second thought was that I could create a single exchange named
    "couchdb_changes", and then add the database name to the routing key.
    When binding queues to the exchange the application would also
    incorporate the database name into the routing key.

    So, are there advantages or disadvantages between the two approaches
    here, or are they largely functionally equivalent. I prefer the feel
    an exchange per observed database; just curious if there are
    established patterns that I should know about to better inform design
    decisions.
    I can think of two main criteria to guide your decision here:

    1) Is the set of DB names fairly static, or does it change quite often?
    In the one-exchange-per-db model the list of exchanges need to be kept
    in sync with the list of databases, which might be tricky depending on
    how/when the list changes.

    2) What kind of subscriptions do you want to support, i.e. how do
    consumers narrow the event stream down to what they want to receive? A
    single topic exchange would give you the most flexibility here, but a
    set of direct exchanges will perform better in most cases.


    Regards,

    Matthias.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedApr 28, '11 at 5:06p
activeMay 15, '11 at 6:43p
posts2
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase