Pub/Sub

What it is

Publish–subscribe decouples publishers (events) from subscribers (handlers). A topic or channel routes messages to many consumers; the broker may be a queue, stream, or managed service (Google Pub/Sub, SNS+SQS, Redis Pub/Sub, Kafka consumer groups).

Fan-out patterns

• Topic fan-out: one published message delivered to many independent subscribers (notifications, search index, analytics).
• Work queue fan-out: competing consumers on one subscription divide work (not duplicate processing)—closer to message-queue-vs-stream.
• Hierarchical topics: orders.created, orders.cancelled for selective subscriptions.

At-least-once consumers

Many brokers guarantee at-least-once: duplicates possible after retries, visibility timeouts, or network redelivery.

Design for idempotency:

• Natural keys and upserts (insert-on-conflict-update).
• Idempotency keys on side effects (payments).
• Dedup store (short TTL) for seen message ids.

When to use

• Event-driven architectures; integrate many services without synchronous coupling.
• Notify many systems of the same business event with independent scaling per consumer.

Alternatives

• Synchronous API calls only: simpler tracing; tight coupling and cascading latency (compare latency-throughput).
• Polling the database for changes: simpler infra; higher DB load and latency than push.

Failure modes

• Slow consumer blocks partition or builds lag—scale consumers, optimize handlers.
• Poison messages—use DLQ and monitoring (same theme as queues).
• Ordering: global order rarely guaranteed across subscribers; use partition keys in streams if needed.

Interview talking points

• Clarify delivery semantics and duplicate handling upfront.
• Size topics and subscriptions with back-of-envelope: events/sec, payload size, peak fan-out.
• Relate to bounded contexts and async eventual consistency.

Related fundamentals

• Back-of-the-envelope estimation
• Latency and throughput