Editing Publish–subscribe pattern (section)

===Message delivery issues===
A pub/sub system must be designed carefully to be able to provide stronger system properties that a particular application might require, such as assured delivery.
*  The broker in a pub/sub system may be designed to deliver messages for a specified time, but then stop attempting delivery, whether or not it has received confirmation of successful receipt of the message by all subscribers. A pub/sub system designed in this way cannot guarantee delivery of messages to any applications that might require such assured delivery. Tighter coupling of the designs of such a publisher and subscriber pair must be enforced outside of the pub/sub architecture to accomplish such assured delivery (e.g. by requiring the subscriber to publish receipt messages).
*  A publisher in a pub/sub system may assume that a subscriber is listening, when in fact it is not.

The pub/sub pattern scales well for small networks with a small number of publisher and subscriber nodes and low message volume. However, as the number of nodes and messages grows, the likelihood of instabilities increases, limiting the maximum scalability of a pub/sub network. Example throughput instabilities at large scales include:
* Load surges—periods when subscriber requests saturate network throughput followed by periods of low message volume (underutilized network bandwidth)
* Slowdowns—as more and more applications use the system (even if they are communicating on separate pub/sub channels) the message volume flow to an individual subscriber will slow

For pub/sub systems that use brokers (servers), the argument for a broker to send messages to a subscriber is [[in-band control|in-band]], and can be subject to security problems. Brokers might be fooled into sending notifications to the wrong client, amplifying denial of service requests against the client. Brokers themselves could be overloaded as they allocate resources to track created subscriptions.

Even with systems that do not rely on brokers, a subscriber might be able to receive data that it is not authorized to receive. An unauthorized publisher may be able to introduce incorrect or damaging messages into the pub/sub system. This is especially true with systems that [[Broadcasting (networking)|broadcast]] or [[multicast]] their messages.  [[Encryption]] (e.g. [[Transport Layer Security]] (SSL/TLS)) can prevent unauthorized access, but cannot prevent damaging messages from being introduced by authorized publishers. Architectures other than pub/sub, such as client/server systems, are also vulnerable to authorized message senders that behave maliciously.