Skip to content
Software Architecture Guide

Message Structure

Explanation

Section titled “Explanation”

A message sent through a messaging system has two parts: a header and a body.

Body. The body holds the data you want to send. The messaging system generally ignores it and passes it along unchanged.

Header. The header holds information that the messaging system itself uses. It describes the data being sent.

Header fields that support replies. Some fields make two-way conversations possible:

  • Request ID. A token that uniquely identifies a request.
  • Correlation Identifier. The replier copies the request ID into the reply. The original sender can then match the reply to its request. See the article Correlation Identifier.
  • Return Address. The request carries this field to tell the replier where to send the reply. It sits in the header because it is metadata, not application data. See the article Return Address.

Expiration. A Message Expiration sets a time limit on how long a message stays viable. Consumers ignore messages that have expired.

Routing. A Routing Slip is attached to a message. It lists the sequence of processing steps, so the message can pass through a series of components. See the article Routing Slip.

Envelope. Most messaging systems split message data into a header and a body. An Envelope Wrapper builds on this. It wraps the application data in an envelope that the messaging infrastructure accepts. The message is unwrapped at the destination. See the article Envelope Wrapper.

Sequences. A large payload can be divided into a sequence of smaller messages. This then requires sequencing, correlation and reassembly. See the article Message Sequence.

Example

Section titled “Example”

An order service sends a request message to a pricing service. The body holds the order lines. The header holds a unique request ID and a return address, the queue where the order service wants answers. The pricing service computes prices. It sends a reply to that queue and copies the request ID into the reply’s correlation ID. The order service reads the reply and matches it to the right order. If the request header also had an expiration time, the pricing service would ignore the request once that time passed.

Trade-offs

Section titled “Trade-offs”

Keeping metadata in the header separates concerns. The messaging system can handle the message without reading the data. The cost is extra work: senders must fill in the right header fields, and repliers must copy the request ID correctly. Splitting a large payload into a sequence of smaller messages lets consumers process chunks independently. It also adds the need for sequencing, correlation and reassembly. An envelope makes a message fit the infrastructure, but it must be unwrapped at the destination.

A request and its reply: the replier copies the request ID into the correlation ID and sends the reply to the return address.

Diagram source 
sequenceDiagram
    participant A as Requester
    participant B as Replier
    A->>B: Request (header: request ID, return address / body: data)
    B-->>A: Reply (header: correlation ID = request ID / body: result)

Checks

Section titled “Checks”
  • Request messages that expect a reply carry a unique request ID, and replies copy it into a correlation ID.
  • Request messages carry a Return Address in the header rather than in the application data.
  • The document states where an expiration time applies and that consumers ignore expired messages.
  • Where large payloads are split into smaller messages, the document describes sequencing, correlation and reassembly.
Section titled “Related”

Sources

Section titled “Sources”