在软件架构中，发布-订阅是一种消息范式，消息的发送者（称为发布者）不会将消息直接发送给特定的接收者（称为订阅者）。而是将发布的消息分为不同的类别，无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者（如果有的话）存在。
发布/订阅是消息队列范式的兄弟，通常是更大的面向消息中间件（英语：Message-oriented_middleware）系统的一部分。大多数消息系统在API中同时支持消息队列模型和发布/订阅模型，例如Java消息服务（JMS）。
这种模式提供了更大的网络可扩展性和更动态的网络拓扑，同时也降低了对发布者和发布数据的结构修改的灵活性。
在发布/订阅模型中，订阅者通常接收所有发布的消息的一个子集。选择接受和处理的消息的过程被称作过滤。有两种常用的过滤形式：基于主题的和基于内容的。
在基于主题的系统中，消息被发布到主题或命名通道上。订阅者将收到其订阅的主题上的所有消息，并且所有订阅同一主题的订阅者将接收到同样的消息。发布者负责定义订阅者所订阅的消息类别。
在基于内容的系统中，订阅者定义其感兴趣的消息的条件，只有当消息的属性或内容满足订阅者定义的条件时，消息才会被投递到该订阅者。订阅者需要负责对消息进行分类。
一些系统支持两者的混合：发布者发布消息到主题上，而订阅者将基于内容的订阅注册到一个或多个主题上。
在许多发布/订阅系统中，发布者发布消息到一个中间的消息代理，然后订阅者向该消息代理注册订阅，由消息代理来进行过滤。消息代理通常执行存储转发的功能将消息从发布者发送到订阅者。
最早公开描述发布/订阅系统之一的是Isis Toolkit的“新闻”子系统，1987年，在计算机协会 (ACM)的操作系统原理的研讨会上，,在论文《在分布式系统中利用虚同步》中。该文描述的发布/订阅技术是由Frank Schmuck发明的。
发布/订阅系统最严重的问题是其主要优点的副作用：发布者解耦订阅者。
发布/订阅系统必须仔细设计，才能提供特定的应用程序可能需要的更强大的系统性能，例如有保障的交付。
在有少量发布者和订阅节点的小型网络和低信息量时发布/订阅能够自如伸缩。然而，随着节点和消息量的增长，不稳定性随之增长，限制了发布/订阅网络的最大可扩展性。大规模时吞吐量不稳定的例子包括：
使用中介（服务器）的发布/订阅系统，同意中介发送消息给带内（英语：In-band_control）订阅者，会引发安全问题。中介可能被愚弄，从而将通知发送给错误的客户端，增大了针对客户端的服务请求被拒绝的可能性。中介本身可能超载，因为他们分配资源来跟踪创建的订阅。
即使不依赖中介的系统，订阅者也可能可以接收未被授权的数据。未经授权的发布者可能将不正确或损坏的消息引入到发布/订阅系统。对于广播或多播消息的系统，这是尤其真实的。加密（例如传输层安全性协议（SSL/TLS）），可以防止未经授权的访问，但不能防止损坏的消息被授权的发布者引入。除了发布/订阅架构，例如客户端/服务器系统，也经常碰到授权的消息发送者有恶意行为。
