
A messaging model in Message-Oriented Middleware (MOM) built around the concept of message queues. In this model, a sender addresses a message to a specific queue, and a receiver extracts the message from that queue.
The defining characteristic of PTP is that each message is consumed by exactly one receiver. Even if multiple receivers are listening to the same queue, the middleware ensures that a specific message is handed off to only one of them, then removed from the system.
PTP Characteristics
- One-to-One Delivery: Unlike broadcast models, PTP is a conversation between one sender and one receiver (or potentially many receivers).
- Message Retention: Messages are stored in the queue until a receiver consumes them or they reach a pre-defined expiration time (Time-to-Live).
- Receiver Independence: The sender does not need the receiver to be active when the message is sent. The queue acts as a buffer, holding data until the receiver is ready.
- Acknowledgment (ACK): Once a receiver successfully processes a message, it sends an acknowledgment back to the queue, which then deletes the message to prevent duplicate processing.
How PTP Works
While PTP is one-to-one for an individual message, you can have multiple receivers attached to a single queue to increase speed. This is known as Load Balancing or Competing Consumers:
- Producer sends 100 messages to
Orders_Queue. - Consumer A and Consumer B are both listening to
Orders_Queue. - The MOM distributes the messages (e.g., 50 to A and 50 to B).
- Each specific order is processed only once, but the work is finished twice as fast.
PTP Components
| Component | Role |
| Queue | The staging area where messages wait in a First-In, First-Out (FIFO) sequence. |
| Sender (Producer) | The application that creates and pushes the message into the queue. |
| Receiver (Consumer) | The application that pulls or receives the message from the queue. |
Use Case Example: Order Processing
Imagine a high-traffic e-commerce site. When a customer clicks “Buy,” the web server sends a message to an Invoice_Queue.
- If the Invoicing Service is slow, messages simply pile up in the queue.
- The web server remains fast because it doesn’t wait for the invoice to be generated.
- As soon as the Invoicing Service has capacity, it pulls the next message, processes it, and sends the ACK.