intermediate

Publish-subscribe

Use pub/sub when multiple subscribers need the same event, but define durability, replay, filtering, and consumer ownership clearly.

Pub/sub lets one published event reach many subscribers independently — billing, search indexing, notifications. Each subscriber progresses at its own pace with separate cursor or offset.

Trade-off: loose coupling and extensibility versus operational overhead tracking many consumer groups and schemas.

On interviews: contrast pub/sub with point-to-point queue for the same OrderPlaced event.

Common pitfalls: subscribers doing synchronous RPC in handler blocking partition; no contract on event schema evolution.

Checklist:

Document each subscriber's SLA and idempotency.
Use schema registry or contract tests.
Avoid slow consumers blocking others on shared infra incorrectly.
Plan new subscribers without producer changes.