[rabbitmq-discuss] help - design pattern for an our use case

stone zmstone at gmail.com
Wed Jul 25 16:14:07 BST 2012


Sorry to hijack this topic, but I'm pretty interested in the topic name
Emile gave in the examples.
It looks like the topic is named from big to small. i.e. bigger topic comes
first then dot then smaller ones.
Is there a specific reason behind this naming convention?
like in routing performance perspective? is it better than the other way
If for example, we have big medium and small, and there is a binding for
"big every thing" is "big.#" better than "#.big" ?


On Wed, Jul 18, 2012 at 1:23 PM, Emile Joubert <emile at rabbitmq.com> wrote:

> Hi,
> On 18/07/12 06:41, Bhaskar teja wrote:
> > What is a good design pattern for our use case - like number of queues?,
> > exchange type?, number of exchanges( web, e-mail ) ??
> This looks like a potential application of topics and a topic exchange.
> Allocate a queue for each user. Bind each user queue with appropriate
> routing keys. So a queue for user "alice" belonging to two communities
> might have these bindings:
> users.alice
> communities.pet-owners
> communities.music-collectors
> When "alice" takes an action that her communities may be interested in
> then a message must be sent to the topic exchange with a routing key for
> each of the communities that she belongs to. It is possible to do this
> in a single operation using CC routing. See
> http://www.rabbitmq.com/extensions.html#sender-selected-distribution
> Depending on the complexity of when groups are notified you could
> implement groups as sub-topics, so a group within pet-owners might be:
> communities.pet-owners.dog-lovers
> Depending on the rules for email notifications you could use a
> combination of dead letter exchanges and queue-TTL to detect when
> notifications have been waiting in the queue for too long and send them
> to the user by email. See:
> http://www.rabbitmq.com/extensions.html#dead-letter-exchanges
> http://www.rabbitmq.com/extensions.html#queue-ttl
> A possible problem with this design is the large number of bindings
> involved. This could be slow and difficult to manage, depending on the
> branching factor. You could contain the complexity by using
> exchange-to-exchange bindings and internal exchanges for groups (and
> communities).
> -Emile
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120725/a09432f6/attachment.htm>

More information about the rabbitmq-discuss mailing list