Pub-Sub Patterns

Why Pub-Sub?

When one action needs to trigger multiple downstream effects — sending a welcome email, updating analytics, invalidating caches — pub-sub keeps each concern isolated. Publishers fire events without knowing who listens. Subscribers react without knowing who fired.

Core Concepts

• Topic — a named channel (e.g. user.created).
• Publisher — emits events to a topic. Stateless fire-and-forget.
• Subscriber — listens on a topic. Idempotent handlers recommended.
• Broker — routes messages. Redis Pub-Sub, RabbitMQ, Kafka, or in-process.

Pattern: Fan-Out

One event, many independent handlers. A payment.succeeded event triggers invoice generation, license activation, and a Slack notification — all in parallel, none blocking the others.

Pattern: Dead Letter Queue

When a subscriber fails repeatedly, route the event to a DLQ instead of dropping it. Inspect, replay, or discard from a dashboard. Prevents poison messages from jamming the pipeline.

At-Least-Once Delivery

Network partitions and restarts mean duplicates happen. Design subscribers to be idempotent — check a processed-event set keyed by event ID before acting. Redis SETNX with a TTL works well for deduplication windows.