Publisher-Subscriber

Producers publish events to a topic or channel without knowing subscribers. All interested subscribers receive every event, decoupling producers from consumers at both the semantic and temporal level.

Multiple downstream consumers need to react to the same events, but the producer should not need to know who they are or maintain direct connections to each one. Adding a new consumer must not require modifying the producer.

In pub-sub, the publisher declares that an event occurred (e.g., "order.placed") and broadcasts it to a topic. Any subscriber that has declared interest in that topic receives a copy. Multiple subscribers receive the same event independently : this is the core distinction from competing consumers, where only one consumer processes each message.

Kafka durable pub-sub: subscribers are consumer groups. Each consumer group receives all events independently. Events are retained on disk for a configurable retention period, so a subscriber added after the fact can replay the full history. This is the most operationally robust pub-sub model for event-driven architectures.

Redis pub-sub: ephemeral. No message persistence. If a subscriber is offline when an event is published, that event is permanently lost to that subscriber. Suitable for real-time fanout (live dashboards, notification delivery) where missing an event is acceptable. Not suitable for event sourcing or audit trails.

SNS/SQS fan-out: SNS topic fans out to multiple SQS queues. Each SQS queue is a competing-consumer pool for one subscriber group. Combines pub-sub semantics (multiple independent consumers) with durable queuing per subscriber. The standard AWS pattern for reliable multi-consumer fanout.

Temporal decoupling: a publisher does not need a subscriber to be online to publish. Events accumulate in the topic. This allows subscribers to be deployed, updated, or restarted independently without the publisher being aware.