[rabbitmq-discuss] Use Case for RabbitMQ

[Robert Raschke]

On Fri, Mar 25, 2011 at 7:13 PM, endy kalu <endy.kalu at gmail.com> wrote:

> I am new to RabbitMQ and Messaging in general. I am building an inventory
> management system and exploring using a messaging system to maintain up to
> date inventory quantities across several geographical locations. There will
> be internet service in these locations but speed is really an issue.
> My questions are:
> 1) Is RabbitMQ or messaging suitable for this.  I like the fact that it can
> push out data and queued till consumed.
> 2) I am .Net and wondering if RabbitMQ can be "embedded" and distributed
> with my application.
> 3) If using RabbitMQ, I am a bit unsure of the architecture. I have
> pondered having RabbitMQ running in all the locations as it seems it's the
> only way to have all server push and receive data.
> 4) I am new to this. I just want to know that this use case is suitable for
> MQ.
>
> I'll really appreciate your thoughts or any direction you can point me.
>
>
The way I see messaging systems is for ease of communication and also
particularly the ease of dealing with a variety of communication patterns
(one to one, broadcast, publish subscribe, etc.).

If you are thinking about using a messaging system as temporary storage,
relying on the fact that you have a queue of persisted messages, then you
have to investigate your sizing constraints. That is, what happens if no one
consumes your persistant messages, when does the message system shut down,
and how do your producers cope with that?

If your primary concern is to "push out data and queued till consumed", then
you might be better off with a DB. Mostly because it is much easier to
reason about and there is an enormous amount of information around to help
you with sizing it correctly.

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110328/c091b11f/attachment.htm>