Pub/Sub

What’s happening under the hood

• ›Fan-out: one publisher writes once, the broker delivers to every subscriber whose subscription set matches the topic. Crucially different from point-to-point queues (where each message goes to one consumer). Redis pub/sub, Kafka consumer groups in broadcast mode, MQTT, and every WebSocket fan-out server implement this same shape — your phone gets the push notification because it subscribed to a topic, not because the server addressed it directly.
• ›Backpressure: the queue grows whenever inbound rate exceeds drain rate. In a single-machine sim this is a `q=12` indicator. In production it's a slow consumer melting a Kafka broker's disk, a WebSocket server running out of socket buffer, or a Lambda hitting its concurrency cap. The dominant production failure mode in real-time systems is not 'the message got lost' — it's 'one consumer is slow and now everyone is'.
• ›Delivery semantics live on a spectrum. At-most-once: fire and forget (UDP, raw WebSockets, default Redis pub/sub) — fast, simple, lossy under failure. At-least-once: the broker holds the message until the consumer acks, redelivering on disconnect (Kafka, RabbitMQ with acks, SQS) — durable, but the consumer must be idempotent because duplicates happen. Exactly-once: only achievable with transactional brokers, idempotent producers, and ack protocols (Kafka with transactions, Pulsar) — the most expensive guarantee in distributed systems, and the one most teams don't actually need.