Messaging & Stream Processing

Publish-Subscribe

Where a queue delivers each message to one consumer, pub-sub broadcasts it to every subscriber of a topic — the shape behind notifications, activity feeds, and event-driven fan-out. Modern brokers like Kafka blend both models via consumer groups.
  • A publisher sends to a topic without knowing who (or how many) subscribers exist — full decoupling of producer from consumer count
  • Every subscriber gets every message on a topic — this is fan-out, the opposite of a queue's one-message-one-consumer delivery
  • Kafka-style logs unify the two models: partitions within a topic give queue-like competing-consumer behavior within a consumer group, while multiple consumer groups each get their own full copy of the stream
  • Ordering is typically only guaranteed within a partition, not across the whole topic — messages needing relative order must share a partition key
  • Slow subscribers are the recurring failure mode: a broker either buffers for them (bounded by retention), drops them, or applies backpressure to the publisher
One publish, many independent subscribers
Each subscriber processes its own full copy of the stream, independent of the others' speed or failures
Queue vs pub-sub vs Kafka-style log
ModelDeliveryOrderingReplay
QueueOne consumer per messageFIFO-ish within the queueNo — consumed messages are gone
Classic pub-subEvery subscriber per messageBest-effort, no strong guaranteeNo — fire-and-forget by default
Partitioned log (Kafka)Every consumer group, competing within a groupGuaranteed per partitionYes — retained and replayable by offset
Sources
  • Designing Data-Intensive ApplicationsCh. 11 — Stream Processing
  • System Design Interview – An Insider's Guide, Volume 2Ch. 7 — Design a Notification System