Publish–subscribe pattern

<h2 id="message-filtering">Message filtering</h2>

<p>In publish–subscribe systems, subscribers typically receive only a subset of messages. The process of selecting relevant messages is called filtering, and it can be implemented in several ways:
</p>
<ul><li>Topic-based filtering: Messages are published to named <i>topics</i> or <i>channels</i>. Subscribers register to receive messages on specific topics, and receive all messages published to them.</li>
<li>Content-based filtering: Subscribers define constraints based on message attributes or content. Messages are delivered only if they match the subscriber's criteria.</li>
<li>Hybrid systems: Some implementations combine topic- and content-based filtering. Messages are categorized by topic, and subscribers apply content-based filters to messages within those topics.</li></ul>
<h2 id="topologies">Topologies</h2>
<p>In most pub/sub systems, publishers and subscribers communicate through a central intermediary such as a <a href="/facts/Message_broker/Rassh8Jd">message broker</a> or event bus. The broker receives messages from publishers and forwards them to the appropriate subscribers, optionally performing <a href="/facts/Store_and_forward/zwM8Amlv">store and forward</a>, <a href="/facts/Priority_queue/1uXVo4Uf">priority queuing</a>, or other routing logic.
</p><p>Subscriber registration can occur at different times:
</p>
<ul><li>Build time: Subscribers are hardcoded to handle specific messages or events (e.g., GUI event handlers).</li>
<li>Initialization time: Subscriptions are defined in <a href="/facts/XML/clNgUfWk">XML</a> configuration files or metadata.</li>
<li>Runtime: Subscriptions can be added or removed dynamically (e.g., <a href="/facts/Database_trigger/yhI7KW6H">database triggers</a>, <a href="/facts/RSS/WBAWrkdj">RSS</a> readers).</li></ul>
<p>Some pub/sub systems use brokerless architectures, in which publishers and subscribers discover each other and exchange messages directly. For example, the <a href="/facts/Data_Distribution_Service/V2fu8coB">Data Distribution Service</a> (DDS) middleware uses <a href="/facts/IP_multicast/YklMRaV5">IP multicast</a> and metadata sharing to establish communication paths. Brokerless systems require construction of overlay networks, often using <a href="/facts/Small-world_network/dALPpt9m">Small-World topologies</a> to enable efficient routing.
</p><p>It was shown by <a href="/facts/Jon_Kleinberg/x9mhMIhN">Jon Kleinberg</a> that efficient decentralized routing requires <a href="/facts/Small-world_routing/y4FGTDc2">Navigable Small-World topologies</a>, which are employed in federated or <a href="/facts/Peer-to-peer/wCCdPb0H">peer-to-peer</a> pub/sub systems.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> Locality-aware pub/sub networks use low-latency links to reduce message propagation time.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a>
</p>
<h2 id="history">History</h2>
<p>One of the earliest publicly described pub/sub systems was the "news" subsystem of the Isis Toolkit, presented at the 1987 <a href="/facts/Association_for_Computing_Machinery/abI2atlP">ACM</a> Symposium on Operating Systems Principles (SOSP '87).<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a>
</p><p>Although the publish–subscribe pattern is now typically distinguished from the <a href="/facts/Observer_pattern/4eGJbxIS">observer pattern</a> due to its emphasis on decoupling and distributed communication, early usage in literature and systems sometimes used the terms interchangeably, especially in the context of in-process event handling or GUI frameworks.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> As distributed systems became more common, the publish–subscribe model evolved to emphasize asynchronous messaging and broker-mediated communication, setting it apart from the more tightly coupled observer pattern.
</p>
<h2 id="advantages">Advantages</h2>

<h3>Loose coupling</h3>
<p>Publishers are <a href="/facts/Loose_coupling/uXRb4qBJ">loosely coupled</a> to subscribers, and need not even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate as per normal independently of the other. In the traditional tightly coupled <a href="/facts/Client%25E2%2580%2593server_model/FSnf27C5">client–server paradigm</a>, the client cannot post messages to the server while the server process is not running, nor can the server receive messages unless the client is running. Many pub/sub systems decouple not only the locations of the publishers and subscribers but also decouple them temporally. A common strategy used by <a href="/facts/Middleware_analyst/Esnp5zN1">middleware analysts</a> with such pub/sub systems is to take down a publisher to allow the subscriber to work through the backlog (a form of <a href="/facts/Bandwidth_throttling/YDU2fa3p">bandwidth throttling</a>).
</p>
<h3>Scalability</h3>
<p>Pub/sub provides the opportunity for better <a href="/facts/Scalability/jh7JomPa">scalability</a> than traditional client-server, through parallel operation, message caching, tree-based or network-based routing, etc. However, in certain types of tightly coupled, high-volume enterprise environments, as systems scale up to become data centers with thousands of servers sharing the pub/sub infrastructure, current vendor systems often lose this benefit; scalability for pub/sub products under high load in these contexts is a research challenge.
</p><p>Outside of the enterprise environment, on the other hand, the pub/sub paradigm has proven its scalability to volumes far beyond those of a single data center, providing Internet-wide distributed messaging through web syndication protocols such as <a href="/facts/RSS/WBAWrkdj">RSS</a> and <a href="/facts/Atom_(standard)/69syB8dH">Atom</a>.  These syndication protocols accept higher latency and lack of delivery guarantees in exchange for the ability for even a low-end web server to syndicate messages to (potentially) millions of separate subscriber nodes.
</p>
<h3>Message delivery issues</h3>
<p>Redundant subscribers in a pub/sub system can help assure message delivery with minimal additional complexity. For example, a factory may utilize a pub/sub system where equipment can publish problems or failures to a subscriber that displays and logs those problems. If the logger fails (crashes), equipment problem publishers won't necessarily receive notice of the logger failure, and error messages will not be displayed or recorded by any equipment on the pub/sub system. In a client/server system, when an error logger fails, the system will receive an indication of the error logger (server) failure. However, the client/server system will have to deal with that failure by having redundant logging servers online, or by dynamically spawning fallback logging servers. This adds complexity to the client and server designs, as well as to the client/server architecture as a whole. In a pub/sub system, redundant logging subscribers that are exact duplicates of the existing logger can be added to the system to increase logging reliability without any impact to any other equipment on the system. The feature of assured error message logging can also be added incrementally, subsequent to implementing the basic functionality of equipment problem message logging.
</p>
<h2 id="disadvantages">Disadvantages</h2>

<p>The most serious problems with pub/sub systems are a side-effect of their main advantage: the decoupling of publisher from subscriber.
</p>
<h3>Message delivery issues</h3>
<p>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.
</p>
<ul><li>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).</li>
<li>A publisher in a pub/sub system may assume that a subscriber is listening, when in fact it is not.</li></ul>
<p>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:
</p>
<ul><li>Load surges—periods when subscriber requests saturate network throughput followed by periods of low message volume (underutilized network bandwidth)</li>
<li>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</li></ul>
<p>For pub/sub systems that use brokers (servers), the argument for a broker to send messages to a subscriber is <a href="/facts/In-band_control/31CkKRce">in-band</a>, 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.
</p><p>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 <a href="/facts/Broadcasting_(networking)/NRj7gHre">broadcast</a> or <a href="/facts/Multicast/D9IspSfl">multicast</a> their messages.  <a href="/facts/Encryption/16q29Fdv">Encryption</a> (e.g. <a href="/facts/Transport_Layer_Security/pGy16TnA">Transport Layer Security</a> (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.
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Atom_(standard)/69syB8dH">Atom</a>, another highly scalable web-syndication protocol</li>
<li><a href="/facts/Data_Distribution_Service/V2fu8coB">Data Distribution Service</a> (DDS)</li>
<li><a href="/facts/Event-driven_programming/QlGL2Fu6">Event-driven programming</a></li>
<li><a href="/facts/High-level_architecture_(simulation)/S5deoo8A">High-level architecture</a></li>
<li><a href="/facts/Internet_Group_Management_Protocol/MEzn1aTF">Internet Group Management Protocol</a> (IGMP)</li>
<li><a href="/facts/Message_broker/Rassh8Jd">Message brokers</a></li>
<li><a href="/facts/Message_queue/Kq7kX86w">Message queue</a></li>
<li><a href="/facts/Observer_pattern/4eGJbxIS">Observer pattern</a></li>
<li><a href="/facts/Producer%25E2%2580%2593consumer_problem/RsVzTSPl">Producer–consumer problem</a></li>
<li><a href="/facts/Push_technology/KoRjtGET">Push technology</a><a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a></li>
<li><a href="/facts/RSS/WBAWrkdj">RSS</a>, a highly scalable web-syndication protocol</li>
<li><a href="/facts/Usenet/lYJWFBR6">Usenet</a></li>
<li><a href="/facts/WebSub/7SBntNva">WebSub</a>, an implementation of pub/sub</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Hohpe, Gregor (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional. ISBN 978-0321200686. <a href="978-0321200686" target="_blank">978-0321200686</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey". Proceedings of the 12th ACM International Conference on Distributed and Event-based Systems. Hamilton, New Zealand: ACM Press. pp. 64–75. doi:10.1145/3210284.3210287. ISBN 9781450357821. S2CID 43929719. <a href="9781450357821" target="_blank">9781450357821</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Rahimian, Fatemeh; Le Nguyen Huu, Thinh; Girdzijauskas, Sarunas (2012), Göschka, Karl Michael; Haridi, Seif (eds.), "Locality-Awareness in a Peer-to-Peer Publish/Subscribe Network", Distributed Applications and Interoperable Systems, vol. 7272, Springer Berlin Heidelberg, pp. 45–58, doi:10.1007/978-3-642-30823-9_4, ISBN 9783642308222 <a href="9783642308222" target="_blank">9783642308222</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Birman, K.; Joseph, T. (1987). "Exploiting virtual synchrony in distributed systems". Proceedings of the Eleventh ACM Symposium on Operating Systems Principles - SOSP '87. pp. 123–138. doi:10.1145/41457.37515. ISBN 089791242X. S2CID 7739589. <a href="089791242X" target="_blank">089791242X</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>The Windows Programming Experience, Charles Petzold, November 10, 1992, PC Magazine (Google Books) <a href="https://books.google.com/books?id=18wFKrkDdM0C&pg=PA230" target="_blank">https://books.google.com/books?id=18wFKrkDdM0C&pg=PA230</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey". Proceedings of the 12th ACM International Conference on Distributed and Event-based Systems. Hamilton, New Zealand: ACM Press. pp. 64–75. doi:10.1145/3210284.3210287. ISBN 9781450357821. S2CID 43929719. <a href="9781450357821" target="_blank">9781450357821</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
</ol>

Publish–subscribe pattern open-in-new

Publish–subscribe pattern