Message Middleware Delivery Models: PTP, Pub/Sub, Partition, and Transfer

The author’s team frequently uses message middleware to decouple services and smooth traffic spikes, prompting a deep dive into typical industry delivery models.

Message Oriented Middleware (MOM) is increasingly vital in enterprise development. This article introduces four MOM delivery models—PTP, Pub/Sub, Partition, and Transfer—detailing their core features and distinctions.

The four models are:

PTP model

Pub/Sub model

Partition model

Transfer model

1. PTP Model – Point‑to‑Point uses a queue where multiple producers and consumers can exist, but each message is consumed by only one consumer and then removed. Messages are ordered in the queue, though consumption may become unordered when multiple consumers process in parallel.

To guarantee ordered consumption, some MQs provide “exclusive consumer” or “single consumer” concepts, allowing only one consumer per queue, which sacrifices parallelism and can cause backlog under high load. Partitioning is later introduced to address this performance issue.

2. Pub/Sub Model – In the publish‑and‑subscribe model, producers publish messages to a topic, and all subscribed consumers receive each message. This is useful when every consumer must process the same data, such as updating in‑memory caches across multiple servers.

An example is a profanity‑filter system deployed on N servers; each server loads the full word list into memory, and updates are broadcast via MQ messages so every server’s consumer updates its cache simultaneously.

3. Partition Model – To overcome the performance limits of exclusive consumers in PTP, systems like RocketMQ and Kafka use partitions. A producer sends a message to a topic, which is routed to a specific partition. Each partition behaves like a sub‑queue, storing only a subset of messages.

Consumers belong to a consumer group; partitions are assigned to consumers within the group, ensuring each partition is processed by only one consumer. This model blends PTP’s single‑consumer guarantee per partition with Pub/Sub’s ability to have multiple consumer groups. However, the number of consumers cannot exceed the number of partitions, which can cause idle consumers.

Some MQs (e.g., RocketMQ) allow parallel consumption within a single partition by launching multiple threads, provided the messages do not require strict ordering.

4. Transfer Model – The author proposes a Transfer model where a topic can have multiple channels. Every message sent to the topic is forwarded to each channel, so each channel holds the full set of messages (or just metadata). Consumers specify the channel they consume from; multiple consumers on the same channel behave like a PTP queue, while different channels act like independent consumer groups, allowing unlimited consumer counts.

This model resembles the NSQ middleware written in Go. It cannot guarantee ordering without exclusive consumers, similar to PTP.

In the author’s company, RocketMQ/Kafka are the primary MQs, using partition models. To break the partition‑count limit, they wrap MQ consumers as FAAS function triggers; function instances can exceed the number of partitions, providing higher concurrency without triggering rebalance.