[rabbitmq-discuss] Exchange and queue design/best practices for social event updates

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