A message-oriented middleware communication model is the reason a shipping service can sit right next to billing on what everyone calls the same channel, and still never see an order event that billing gets every time. In the previous article, we discussed message-oriented middleware as the layer underneath every queue, broker, and event bus, and named three decisions a team makes about it, on purpose or by accident, before a line of application code exists. This is the first of those three: the communication model that decides who is even allowed to receive a message.

Point-to-point delivers a message to exactly one consumer. Publish-subscribe delivers a full copy of that message to every consumer who asked for it. That is the entire distinction, and it is also the whole reason two systems built on what a job posting would call “the same kind of queue” can fail in exactly opposite directions under load.

Point-to-point and publish-subscribe: the two message-oriented middleware communication models

Both names, and the vocabulary the whole industry still uses to talk about them, come from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf, more than twenty years old and still the reference for this layer.

A Point-to-Point Channel guarantees that only one receiver consumes a given message, even when several receivers are listening on the same channel at once. The receivers do not have to coordinate with each other; the channel resolves the race. That guarantee is what makes it the right shape for a job queue: ten workers can pull from the same channel, and a job is not processed twice, not because the workers agreed on anything, but because the channel itself will not hand the same message to two of them.

A Publish-Subscribe Channel does the opposite. It delivers a copy of the message to each output channel, and each subscriber gets that message exactly once, independently of how many other subscribers exist. Nobody races for the job; everybody who subscribed gets their own copy. That is the shape for an event: an order was placed, and billing, shipping, and a fraud model all need to know, none of them competing with the others for the privilege.

Six properties every message-oriented middleware communication model has to answer

Underneath the pattern name, every messaging system has to answer the same short list of properties, whatever it calls them in its own documentation: persistence, failover, guaranteed delivery, ordering, transaction, and clustering. The pattern does not remove any of these questions. It just changes what a workable answer looks like.

• Persistence: whether a message is kept when nobody is there yet to receive it. Holding an unconsumed message until a consumer shows up is the default job of a queue. A topic drops a message the moment it is published unless a subscriber registered as durable, in which case the middleware holds a copy just for that subscriber until it reconnects. Persistence is the default in a queue and opt-in, per subscriber, in a topic.
• Failover: whether a client reconnects automatically after a broker failure. In point-to-point, any worker pulling from the surviving queue can pick up a job a failed worker never finished, since the guarantee was always “someone gets it,” never “this worker gets it.” In publish-subscribe, failover only restores what a durable subscription already promised to hold; a non-durable subscriber offline during the failure has nothing to reconnect to.
• Guaranteed delivery: at-least-once, at-most-once, or exactly-once. A point-to-point channel only has to satisfy one consumer, so a single acknowledgment settles the question. A publish-subscribe channel has to satisfy every subscriber on its own terms, and a publisher can easily assume a subscriber is listening when it is not; holding the guarantee for all of them usually means acknowledgment machinery the pattern does not provide on its own.
• Ordering: whether messages arrive in the order they were produced. A single queue with a single consumer keeps order for free. Add a second worker to that queue for throughput, and order across workers is no longer guaranteed, only order within whichever worker took a given message. A topic keeps order within each subscriber’s own copy, but promises nothing about when two subscribers each finish with theirs.
• Transaction: whether several sends and receives count as one atomic unit, with a rollback option. This sits more comfortably in point-to-point, where a rollback just means putting one message back on one queue for the one consumer that will eventually take it. In publish-subscribe, a rollback after subscribers have already acted on their copies has nothing left to undo; the transaction boundary has to sit before the fan-out, not after it.
• Clustering: whether a network of brokers works together for availability and load. Clustering a queue has to preserve the one-consumer guarantee across every node, so two brokers never hand the same message to two different consumers, which takes real coordination. Clustering a topic is more forgiving: every subscriber already expects its own copy, so the cluster only has to fan out faithfully, not prevent duplication.

What happens when nobody is listening

The property that exposes the difference fastest, and the one worth testing before anything else, is what a message-oriented middleware communication model does when it is produced into an empty room. A point-to-point queue keeps it: that is the entire reason a queue exists, to absorb the gap between a producer that is ready now and a consumer that isn’t yet. A publish-subscribe topic, by default, does not; the message is gone the instant it is published, unless a subscriber had already registered, durably, to catch what it misses.

Neither behavior is a defect. A queue that discarded unconsumed work would be useless as a queue. A topic that stored every message forever, for subscribers that might never show up, would need to decide how long “might” lasts, which is exactly what durable subscriptions let a team decide on purpose, instead of discovering it in production.

The guarantee, not the topology, is the answer

The two patterns blur at the edges. A durable subscription makes a topic behave like a queue for that one subscriber, holding what it missed until it reconnects. A pool of independent worker groups, each reading its own copy of a point-to-point-style channel, can start to look like fan-out from a distance without ever being a topic. One can supplement the other inside the same system, as long as the team can say, for the piece in front of them, which guarantee is actually in force. What decides that is never the diagram; it is the six properties above, answered honestly for the channel already running.

That is also why the same feature name keeps meaning different things across systems that all call themselves message-oriented middleware. “Guaranteed delivery” on a queue and “guaranteed delivery” on a topic answer different questions, one consumer’s worth of an answer against every subscriber’s worth of one, and a team that assumes they match finds out otherwise the first time a consumer goes quiet. Map every consumer relationship to one-to-one or one-to-many before picking a message-oriented middleware communication model, write down what each of the six properties actually guarantees for the channel in use, and test, on purpose, what happens to a message when nobody is listening. Same feature name, different guarantee, every time.

The protocol running underneath either model, and whether a broker sits in the middle at all, are their own decisions, covered in the next pieces in this series before Kafka gets one of its own. Where in your system does a point-to-point queue actually need to be a topic, or the other way around?