[rabbitmq-discuss] Exchange and queue design/best practices for social event updates
Michael Bridgen
mikeb at rabbitmq.com
Wed Mar 23 14:47:41 GMT 2011
Hi Alex,
> The following is the basic requirements of our system:
>
> The whole application is called community. Inside community we have groups.
> In each group, user can have discussion topics within the group.
> User can share file/resource to community.
> There is a wall page for user. Also there is a wall page for the group.
>
>
>
[...]
>
> This is my initial plan:
In general, mapping your application domain directly to a messaging
system isn't a good approach. Instead, you ought to determine what
kinds of services your application needs from the messaging system, then
work out how to implement them.
Usually the required services boil down to a fairly small set of
messaging patterns. These are explained in our tutorials:
http://www.rabbitmq.com/getstarted.html
Software architecture is of course subject to fashion, but this book
seems to be a fairly stable point: http://www.eaipatterns.com/
> - planning to use *topic exchange* for that.
Topic exchanges make a good "message bus" stand-in, so that may be
appropriate for notifications.
> - use queues binding such as ( #.self , #.friends, #.group,
> #.groupmembers, #.otheractors )
>
>
> But my concern is:
>
> - how do we mix together the *TARGET* and *ACTION* so that one routing
> key will cover all possible combination?
I think you will want different semantics for different actions, so I
wouldn't lump them together.
For example, for updates, you really just want to queue things until you
can process them; in this case, you'd use the work queue pattern, and
send things directly to a particular queue.
> - do I require to send 2 messages with different routing keys to get the
> possible combination? (which I don't really want to since the publisher
> will have too much knowledge about the business rule)
Yes, you will want to insulate the components that produce events from
those that process them. But inevitably, some components will want to
accomplish more than one thing -- e.g., queue a job to resize a picture
AND respond to the user -- in which case it may have to send more than
one message.
> - Is it the right approach? Or should I just have either of ACTION or
> TARGET and have the consumer decide based on the event type?
>
> - What is the recommended number of exchanges for such situation?
Exchanges are cheap. Just think of them as namespaces for routing. So
the answer is "As many as you need".
> - Would be great if you could suggest the good naming practice for queue
> and exchange.
For queues that are work queues, supply a name meaningful to your
application. For convenience, queues that are tied to a particular
application resource and need to be durable, can be named for that
resource -- e.g., "<user>-notifications". For any other queues, let the
server name them.
For exchanges, supply a name meaningful to your application.
Kind regards,
Michael
More information about the rabbitmq-discuss
mailing list