Hi All,

I'm new to RabbitMQ and planning to use RabbitMQ in our social application.
Would like to receive more advices on design approaches and best practices
form you all.

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.



(EVENT-1 :: if user share a file/resource to community)

- update on wall of that user

- update on wall of all friends

- add to moderation queue

*TARGET*: self, friends;

*ACTION*: update wall, add to moderation


(EVENT-2 :: if someone comments on shared file/resource of community)

- update on wall of that user (primary actor)

- update on wall of all other people (other actors) who also commented on
the resource

- update on wall of all friends of primary actor

- notify to all other people (other actors) who also commented on the
resource

*TARGET*: primary actor, friends, other actors;

*ACTION*: update wall, notify


(EVENT-3 :: admin delete particular file/resource from community)
- clean up work
- notify the owner
*TARGET*: owner
*ACTION*: clean up, notify


(EVENT-4 :: if user post a conversation to certain discussion topic within
the group)

- update to group wall

- update to group members' wall

- notify to all group members

- classify trending of the discussion

*TARGET*: group, group members

*ACTION*: update wall, notify, classify trending



This is my initial plan:

- planning to use *topic exchange* for that.

- 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?

- 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)

- 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?

- Would be great if you could suggest the good naming practice for queue and
exchange.


OR if my approach is not appropriate, please kindly suggest the workaround
and fixes so that I could learn.


Thanks guys.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110317/0d60a51b/attachment.htm>

Search Discussions

  • Michael Bridgen at Mar 23, 2011 at 2:47 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedMar 18, '11 at 3:41a
activeMar 23, '11 at 2:47p
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Lin Tun: 1 post Michael Bridgen: 1 post

People

Translate

site design / logo © 2022 Grokbase