Exchange use cases

This page collects a number of use-cases for exchanges, contributed by various people.

Publish / Subscribe

1. There is arbitrary number of message publishers
2. The messages published tend to be short and plentiful
3. Quick delivery is paramount
4. Reliability in not a priority (undeliverable messages are dropped)
5. Message ordering can be compromised (?) to improve performance
5. There are multiple subscribers, each of the subscribing for a subset of messages
6. Subscriber expects at most one message delivery (?), even if the message matches multiple subscriptions by the subscriber

Example: Stock price feed
Use case provided by: Martin Sustrik

Request / Reply

1. Client A publishes a message (request)
2. Message is delivered to client B
3. Client B processes the message and publishes a reply
4. Reply is delivered back to client A
5. Client A processes the reply
6. Messages in this scenario may not be delivered more than once
7. Reliability is paramount, performance can be compromised
8. Message ordering is irrelevant as there is at most 1 message being passed at any given time
9. The requests that cannot be delivered to their destination are either queued and wait till destination becomes available OR (app level decision) are returned to sender (after possible timeout) to notify it about request failure.

Example: RPC
Use case provided by: Martin Sustrik

Asynchronous requests

1. Client A sends a message (request)
2. Message is delivered to client B
3. Client B processes the request and sends error message to A in case processing fails
4. If processing succeeds, nothing is sent back to A
5. Client A may send next request immediately after sending the first one, no waiting for reply is required
6. Messages in this scenario are never spawned
7. Reliability is paramount, performance can be compromised
8. Message ordering is vital
9. The requests that cannot be delivered to their destination are either queued and wait till destination becomes available OR (app level decision) are returned to sender (after possible timeout) to notify it about request failure.

Example: AMQP itself (asynchronous commands as Basic.Publish)
Use case provided by: Martin Sustrik

Broadcast

1. Client A sends a message (request)
2. Request is delivered to arbitrary number of clients
3. Each client processes the message and does not send a reply
4. Reliability is paramount, performance can be compromised
5. Message ordering is vital
6. The requests that cannot be delivered to their destination are either queued and wait till destination becomes available OR (app level decision) are returned to sender (after possible timeout) to notify it about request failure OR are dropped silently

Example: Sending shutdown command to all apps system-wide
Use case provided by: Martin Sustrik

Notifying about non-immediate delivery

1. Message is sent by client A
2. If client B is available it is sent to it
3. If it is not available, message is queued for later delivery and a notification is sent back to the sender
4. Message ordering between A and B should be guatanteed

Use case provided by: Steve Shaw, Martin Ritchie

Exchange as a proxy for remote exchange

1. There is exchange E on both broker A and broker B
2. Messages are published to E on A
3. They are passed by clustering mechanism to B and republished to E at the place
4. If message cannot be delivered on B, rejection message should be delivered back to A

Example: clustering, bridging the exchanges among brokers
Use case provided by: Martin Sustrik

amq.return exchange

1. Message is sent to an exchange
2. If it does not match any of the bindings, it is sent to another exchange

Example: Proposed message returning mechanism
Use case provided by: Martin Sustrik

Service exchanges

1. Exchange acts as embedded service.
2. Application sends message to exchange with some routing-key.
3. Routing key identifies internal service.
4. Internal service parses message and responds back to application.

Example: console service.
Comment: this model can be expanded to allow arbitrary services to run within the broker, much like web applications (mod_perl).
Another comment: This is much similar to request/response model with the exception of service being not an external application, but a broker itself.
Use case provided by: Pieter Hintjens

Selectors/Filtering

1. Consumers want to filter the set of messages that are actually delivered to them
2. Server-side filtering is desired (perhaps for efficiency reasons)

Comment: The headers exchange does this in part. Other uses may require more sophisticated matching.
Use case provided by: Gordon Sim

Transformation

1. Want to allow server-side transformation of messages (e.g.) to modify 'old' format of messages to 'new' format
2. A bit controversial perhaps(!)

Comment: As exchanges are currently the only extension point that is open without losing interoperability this sort of thing seems bound to crop up.
Use case provided by: Gordon Sim

Aggregation

1. Publisher sends a logical message in n parts (e.g. for an order, it has been written to send a message for each individual item)
2. Consumer wants to deal with a single logical message as an aggregation of the individual parts
3. An exchange is (perhaps controversially) one option (another is a separate client that does this more 'explicitly')

Comment: I wouldn't necessarily say we have to support this type of thing, but again I think it will inevitably be something people consider.
Use case provided by: Gordon Sim

Reordering

1. Publishers send in messages
2. Consumer expects them in an application defined order
3. Exchange could be used to do this

Comment: the same reservations apply here as noted for the last two cases.
Use case provided by: Gordon Sim

Notifying about the size of the queue

1. When number of messages in a queue reaches certain limit, notification is sent to client.

Example: Batch-job processing
Use case provided by: John O'Hara

Passing message to two handlers

1. Message is sent by client A
2. It is delivered to client, who registers as 'primary handler'
3. If primary handler is unavailable, it is sent to client who registers as 'secondary handler'
4. If none of the handlers is available, message is returned to the sender

Use case provided by: Robert Grieg, Martin Ritchie (IIRC)

JMS queues with selectors

1. Several consumers subscribe to the same point (JMS queue) with different message filetering conditions.
2. Messages are expected to arrive in more-less round-robin fashion.

Comment: This use cases arises when implementing JMS over AMQP
Use case provided by: Robert Grieg

Add a New Comment