Point-to-Point Channel

A Point-to-Point Channel guarantees that each message placed on it is delivered to exactly one receiver. Several consumers may listen, but the messaging system ensures only one of them processes any given message. This is the natural model for distributing units of work or sending commands that must execute once.

The problem it solves is duplication. If a message represents a task — charge a card, ship an order, send an email — you must not run it twice. A point-to-point channel makes single processing the default behavior of the transport rather than something each consumer must coordinate.

How It Works

The messaging system implements the channel as a queue. Producers enqueue messages. Consumers dequeue them. When a consumer takes a message, the broker marks it in-flight and hides it from other consumers. On successful acknowledgment, the broker deletes it. If the consumer fails to acknowledge within a timeout, the broker returns the message to the queue for redelivery.

When many consumers attach to one queue, they form competing consumers and the broker load-balances messages across them. This scales throughput while preserving the one-message-one-receiver guarantee.

Producer --> [ queue ] --> { Consumer A | Consumer B | Consumer C }
            (exactly one consumer gets each message)

When to Use It

Use it for command messages and work queues: any case where a message should trigger exactly one action. It fits task distribution, background job processing, and request handling where horizontal scaling of consumers is desirable.

Do not use it when multiple independent subscribers each need their own copy of an event — that requires a publish-subscribe channel.

Trade-offs

Point-to-point channels are simple and resilient, with built-in load balancing and redelivery. The main subtlety is delivery semantics: most queues offer at-least-once delivery, so a consumer crash after work but before acknowledgment causes redelivery. Consumers should therefore be idempotent. Strict global ordering across competing consumers is generally lost; if order matters, partition the channel or use a single consumer.

Related Patterns

Contrast with the Publish-Subscribe Channel, which copies each message to every subscriber. Competing Consumers describes scaling consumers on one queue. An Idempotent Receiver protects against redelivery duplicates.

Example

Amazon SQS standard queues, RabbitMQ classic queues, and a single Kafka consumer group all implement point-to-point semantics. A payments worker pool reads from a charges queue; SQS hands each charge request to one worker, and a visibility timeout returns unacknowledged messages so no charge is silently dropped.