Skip to content
Software Architecture Guide

Invalid Message Channel

Explanation

Section titled “Explanation”

A receiver sometimes gets a message that makes no sense to it. The Invalid Message Channel pattern answers one question: how can the receiver handle such a message gracefully?

The solution is simple. The receiver moves the improper message to a special, dedicated channel. That channel holds messages that their receivers could not process. (A channel is the path that carries messages between systems. See Message Channel.)

How it differs from a Dead Letter Channel. The two patterns solve different problems. A Dead Letter Channel covers what the messaging system does with a message it cannot deliver. The Invalid Message Channel covers a message the receiver judges to have unusable content. See Dead Letter Channel.

Products blur the line. Azure Service Bus has a dead-letter queue (DLQ). It holds messages that cannot be delivered or processed. Applications can also put messages there on purpose, for example messages with malformed payloads or failed message-level authentication. That second use resembles an Invalid Message Channel.

Error metadata. A rejected message is easier to diagnose when it carries the reason. Service Bus adds a dead-letter reason and a description to each dead-lettered message. Applications can define their own reason codes. Microsoft recommends putting the exception type in the reason and the stack trace in the description. A Dead Letter Channel can also record where the message died.

Repeated failures. A message that keeps failing is called a poison message. Brokers cap the retries with a counter:

  • In Amazon SQS, each redelivery raises the message’s receive count. At a configured limit, the message moves to a dead letter queue.
  • In Service Bus, the default maximum delivery count is 10. Past it, the message moves to the DLQ with the reason MaxDeliveryCountExceeded.

What happens next. In Service Bus, people can remove and inspect dead-lettered messages. A user may correct and resubmit them once the cause is fixed.

Example

Section titled “Example”

An order service reads messages from an “orders” channel. One message arrives with a garbled body. The service cannot read it, so it moves the message to an “orders-invalid” channel. It adds a short reason, such as “payload not readable”. Later, a support engineer opens that channel, finds the cause, fixes the data, and sends the message again.

Trade-offs

Section titled “Trade-offs”

Dead-lettered messages do not clean themselves up. In Service Bus they stay until someone explicitly retrieves and completes them. Without an owner, the channel can fill with unhandled messages.

Retry limits are a trade-off. A low limit moves failing messages out of the way quickly. A higher limit gives temporary problems more chances to clear. The facts here give no rule for choosing the number.

A receiver routes messages it cannot process to a dedicated channel.

Diagram source 
flowchart LR
  A[Original channel] --> R{Receiver}
  R -->|understood| P[Process message]
  R -->|not understood| I[Invalid Message Channel]
  I --> H[Inspect, correct, resubmit or remove]

Checks

Section titled “Checks”
  • The document names a dedicated channel where the receiver puts messages it cannot process.
  • The document separates receiver-judged invalid content from delivery failures handled by the messaging system (Dead Letter Channel).
  • Rejected messages carry error metadata such as a reason and description.
  • A retry or delivery limit caps repeated failures of poison messages.
  • The document says who inspects, corrects, resubmits, or removes messages in the invalid channel.
Section titled “Related”

Sources

Section titled “Sources”