Pub/Sub Messaging Pattern Design Template

A message queue delivers each message to exactly one consumer (point-to-point). Pub/sub delivers each message to every subscriber of the topic (fan-out). Use a queue when one service needs to process each message. Use pub/sub when multiple services need to react to the same event independently. Many architectures combine both: pub/sub for fan-out, with each subscription backed by a queue for reliable consumption. The [Technical PM Handbook](/technical-pm-guide) covers how these patterns fit into broader system architecture.

Most pub/sub platforms do not guarantee global message ordering. If ordering matters, use an ordering key (e.g., `userId`, `orderId`) so that messages with the same key are delivered in order. This limits parallelism per key but preserves ordering where it matters. If you need global ordering, consider a single-partition Kafka topic instead. For many use cases, designing consumers to handle out-of-order messages (via timestamps or sequence numbers) is simpler than enforcing order at the infrastructure level.

Each subscriber operates independently. If the email subscriber falls behind, the push subscriber is unaffected. The key risk is a subscriber that never acknowledges messages, causing the topic to retain messages indefinitely (increasing storage costs). Set message retention limits per topic and dead letter policies per subscription to contain the blast radius of a misbehaving subscriber.

Use pull delivery when your subscriber controls its own processing rate and you want to batch messages for efficiency. Use push delivery when you need lowest-latency delivery and your subscriber is an always-on HTTP endpoint. Pull is more common in backend services. Push is useful for serverless functions (Cloud Functions, Lambda) that need to be triggered by messages. ---