# Message Channel

**In short:** A message channel is a pipe between applications. One application writes messages into it, and another reads them out. The sender does not need to know the receiver. Channel types cover delivery, message types, errors, and durability.

## Explanation

A message channel is a pipe in a messaging system. One application writes information into the channel. Another application reads it from the channel. The sender does not need to know which application will pick the message up.

**Choosing who receives a message**

- A *Point-to-Point Channel* makes sure only one receiver gets each message. Several receivers can compete for messages without coordinating with each other. See Point-to-Point Channel.
- A *Publish-Subscribe Channel* delivers a copy of each event to every subscriber. Inside, it has one input channel that splits into one output channel per subscriber. See Publish/Subscribe Channel.

**Organizing messages by type**

A *Datatype Channel* uses one channel per data type. The receiver then knows the type of a message from the channel it arrived on. See Datatype Channel.

**Connecting applications**

A *Channel Adapter* connects an application that does not use messaging. The adapter works through the application's API or data. It acts as a messaging client and publishes messages on a channel.

**Handling problems**

- A *Dead Letter Channel* takes messages the system cannot or should not deliver. Exactly how it works depends on the messaging system. See Dead Letter Channel.
- *Guaranteed Delivery* stores messages in a built-in data store. They then survive a crash of the messaging system. A send only completes once the message is safely stored in the sender's data store.

**Sharing channels across applications**

A *Message Bus* combines a common data model, a common command set, and a messaging infrastructure. Together they act as shared channel middleware between applications.

## Example

An online shop has an order application and several other systems. The order application writes each new order to a channel. If only one worker should process each order, the shop uses a point-to-point channel. If billing, shipping, and reporting all need to see the order, it uses a publish-subscribe channel. The order application does not know who reads its messages. A separate channel holds only invoices, so readers know what they receive.

## Trade-offs

Channels let the sender stay unaware of its receivers. That is the main benefit, and it comes from the pipe design itself.

Some choices carry costs that the facts make visible:

- Guaranteed Delivery protects messages from crashes. The cost is that a send does not complete until the message is stored safely.
- A Dead Letter Channel behaves differently in each messaging system. Check what your system does.
- One channel per data type (Datatype Channel) means more channels to manage.

A publish-subscribe channel: one input channel splits into one output channel per subscriber.

```mermaid
flowchart LR
  S[Sender] --> IN[Input channel]
  IN --> O1[Output channel A]
  IN --> O2[Output channel B]
  O1 --> R1[Subscriber A]
  O2 --> R2[Subscriber B]
```

## Checks

- The document states whether each channel is Point-to-Point (one receiver per message) or Publish-Subscribe (a copy per subscriber).
- Each channel carries one data type, so receivers can tell the message type from the channel.
- Non-messaging applications are connected through a Channel Adapter.
- The document describes how undeliverable messages are handled, such as with a Dead Letter Channel, and how this works in the chosen messaging system.
- Where messages must survive a messaging system crash, the document states that Guaranteed Delivery is used.

## Related

- [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md)
- [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md)
- [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md)
- [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md)
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md)

## Sources

- [Message Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Point-to-Point Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PointToPointChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Publish-Subscribe Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-08
- [Datatype Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DatatypeChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Channel Adapter - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelAdapter.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Dead Letter Channel - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Guaranteed Delivery - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/GuaranteedMessaging.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Message Bus - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBus.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09