podviaznikov
commented
9 years ago only pass ID's in messages, have actual data in some database
I guess it is not applicable for us in some cases. E.x. docker-listener needs to put docker event info into the message.
some notes for rabbitMQ message passing / broker usage.
3 patterns for message passing:
pub/sub - event emitter:
Command
a command message should have the subject explicitly stated. This will prevent confusion and simplify the handling of commands. Command names should represent a high level concepts, not specific details. using a fanout exchange for a command is a bad idea. command messages are usually handled by direct exchanges. using routing keys to ensure the command message is delivered to the correct queue. You should note, however, that it is possible for a single message to hit multiple destination queues by having more than one binding on the exchange, using the same binding key. Take care not to allow this to happen without very explicit intention. Having multiple handlers for a single command message can result in duplicated work and results. A command should be used to alter the state or data of a system
request/response
There are two pieces of information that must be included in a request, if a response is expected. The first is a correlation ID. This is a unique ID that the requestor generates for that one request. It is included in the meta-data of the message and must be included in the response message. Having the correlation ID in the response allows the requestor to know which chunk of code should handle the response. Without the correlation ID, it would be impossible to have multiple requests going out at the same time. This is where the reply-to queue comes in. In RabbitMQ, the response is sent through an exclusive (private) queue that the requestor sets up just for responses. The location or address of this private queue is sent with the request message in the same manner as the correlation ID. Once the request handler code has produced the desired response, it sends the response message to the reply-to queue, setting the correlation ID from the original request. A request, on the other hand, should never alter the state of the system request should have timeout, which if hit should update the system then it should ignore subsequent response.
extra: