Skip to content
Software Architecture Guide

Messaging

Explanation

Section titled “Explanation”

Messaging is an integration style: applications connect to a common messaging system. They exchange data and invoke behavior by sending messages through it. It is a pragmatic reaction to the problems of distributed systems (see Integration Style).

Decoupling in time. Sending a message does not require both systems to be up and ready at once. The messaging system holds the message until the receiver can take it. This is called store-and-forward.

Looser links. Messaging keeps much of the decoupling that file transfer offers. The messaging system can also change a message in transit. Neither sender nor receiver needs to know about that change.

Channels. Messages travel over channels (see Message Channel). Two kinds matter most:

  • A point-to-point channel makes sure only one receiver consumes each message (see Point-to-Point Channel).
  • A publish-subscribe channel announces an event by delivering a copy to every receiver (see Publish/Subscribe Channel).

Routing. A content-based router looks at each message and sends it to the right recipient channel based on its content (see Content-based Router).

Delivery guarantees. Guaranteed Delivery stores messages on disk until the receiver acknowledges them. They then survive a crash of the messaging system. Most brokers offer at-least-once delivery, so duplicates can occur. Exactly-once delivery across a distributed system is impractical.

Duplicates and order. A producer may send a message, miss the acknowledgment because of a network fault or timeout, and send it again. The broker then holds two copies. A consumer that ignores duplicates, using a stable deduplication key, achieves effectively-once processing (see Idempotent Receiver). Deduplication does not guarantee order. Ordering needs sessions or sequence/version data so the consumer can reject stale messages.

Example

Section titled “Example”

An online shop sends an “order placed” message. The messaging system stores it. The invoicing system is down for maintenance, so it reads the message later when it is back. The shop never waited for it. If the shop resends the message because an acknowledgment was lost, invoicing checks the order number and ignores the second copy.

Trade-offs

Section titled “Trade-offs”

Messaging gives decoupling in time and lets messages be transformed or routed without the endpoints knowing.

The guarantees have limits. At-least-once delivery means duplicates, so consumers must handle them. Exactly-once is impractical across a distributed system. Removing duplicates does not restore order, so ordering needs extra data or sessions.

A sender hands a message to the messaging system, which stores it until the receiver acknowledges it.

Diagram source 
flowchart LR
  S[Sender] --> C[Channel in messaging system]
  C -->|stored until acknowledged| R[Receiver]

Checks

Section titled “Checks”
  • The document states which channels are point-to-point (one consumer per message) and which are publish-subscribe (a copy to each receiver).
  • The document states the delivery guarantee in use and whether messages are persisted until acknowledged.
  • Consumers that can see duplicate messages say how they ignore them, for example with a stable deduplication key.
  • Where message order matters, the document names the mechanism, such as sessions or sequence/version data.
Section titled “Related”

Sources

Section titled “Sources”