Pub/Sub

Pub/Sub (Publish-Subscribe) is a messaging pattern in which producers publish messages to a named channel (topic) without knowing who consumes them, and consumers subscribe to topics they care about without knowing who produced the messages. The pattern decouples producers from consumers, enabling fan-out, replay, and asynchronous processing.

How it differs from queues

• Queue (point-to-point). Each message is consumed by one of N workers. Used for work distribution.
• Pub/Sub (fan-out). Each message is delivered to every interested subscriber. Used for event broadcast and integration.

Many modern brokers support both patterns through different channel types or consumer-group semantics.

Common implementations

• Streaming brokers: Apache Kafka, Redpanda, AWS Kinesis, Azure Event Hubs, NATS JetStream, Pulsar. Messages are durable, replayable, ordered within partitions.
• Cloud-managed: Google Pub/Sub, AWS SNS (with SQS), Azure Service Bus topics, Cloudflare Queues.
• In-process / low-latency: Redis Pub/Sub, NATS Core, ZeroMQ. Fast, often fire-and-forget.
• Traditional message brokers: RabbitMQ, ActiveMQ, IBM MQ. AMQP, STOMP, MQTT protocols.

Delivery semantics

• At-most-once. Messages may be lost but never duplicated.
• At-least-once. Messages are never lost but may be redelivered; consumers must be idempotent.
• Exactly-once. Each message processed once; expensive and often achieved through idempotency plus transactional offsets.

🔗

Related Terms Event-Driven Architecture, Redis, Microservices, Webhook, Idempotency.