Skip to main content
Welcome — in this lesson you’ll learn how Cloud Pub/Sub delivery guarantees work and how subscriber acknowledgments affect message reliability. We cover the two delivery models Pub/Sub supports, explain their behavior, and show when to choose each approach for robust, production-ready messaging. There are two primary delivery guarantees:
  • At‑least‑once (the default)
  • Exactly‑once
We’ll define each, show common causes of duplicates or message loss, and give practical guidance for designing subscribers and downstream systems.

​
At‑least‑once delivery (default)

At‑least‑once is Pub/Sub’s default delivery guarantee: every published message will be delivered to subscribers at least once, so messages are never silently lost. However, individual messages can be delivered multiple times. Duplicates most often arise when:
  • A subscriber delays an acknowledgement
  • The ack deadline expires before processing completes
  • Network retries or transient errors cause redelivery
Because duplicates are possible, subscribers must be built to tolerate repeated deliveries by using stable IDs, idempotent operations, or explicit deduplication logic.
Slide titled "Cloud Pub/Sub Delivery Guarantees" showing that the default is "At‑Least‑Once Delivery." It notes messages may be duplicated if acknowledgments are delayed or retried, ensuring no message loss but requiring subscribers to handle duplicates.
Why this matters for engineers
  • Use a stable, application-level message identifier so repeated IDs can be detected and ignored.
  • Implement idempotent processing: handling the same message multiple times should result in the same state as handling it once.
  • Add a deduplication layer (in memory, in a database, or in an external service) when absolute uniqueness is required.
A slide titled "Cloud Pub/Sub Delivery Guarantees" showing "At-Least-Once Delivery" (the default) with a truck icon. It notes the use case: best when reliability matters more than occasional duplication (e.g., logging, metrics ingestion).
Use cases
  • Logging and metrics ingestion where occasional duplicates are acceptable.
  • Telemetry and analytics event collection where completeness is more important than perfect uniqueness.
  • Any pipeline where losing messages is unacceptable but downstream systems can handle or deduplicate repeats.
When asked about Cloud Pub/Sub’s default delivery mode, the correct answer is at‑least‑once delivery.

​
Exactly‑once delivery

Exactly‑once aims to ensure each published message is delivered and processed exactly one time. Implementing exactly‑once semantics usually combines:
  • Precise acknowledgement and checkpointing,
  • Idempotency or deduplication in the subscriber or downstream systems,
  • Integrations with tools that support deduplication (for example, Cloud Dataflow).
Exactly‑once eliminates duplicates but increases operational complexity and cost. If a message is acknowledged as processed under an exactly‑once setup, Pub/Sub will not re‑deliver it — so recovery and auditing strategies are essential to prevent data loss.
Exactly‑once reduces duplicates but requires careful operational controls. If processing fails after acknowledging a message, recovery can be difficult—plan for auditing, retries, or replay mechanisms outside Pub/Sub.
A presentation slide titled "Cloud Pub/Sub Delivery Guarantees." It highlights "Exactly-Once Delivery" and notes it uses acknowledgment tracking, idempotency checks, and integration with Cloud Dataflow or a deduplicating subscriber.
When to use exactly‑once Use exactly‑once delivery when duplicates would cause serious correctness or financial problems and you can accept the extra design and operational cost:
  • Financial transactions and billing systems (to avoid double charges).
  • Stateful workflows or counters where duplicate events would corrupt state.
  • Mission-critical reconciliation processes requiring strict uniqueness guarantees.
A slide titled "Cloud Pub/Sub Delivery Guarantees" with an icon and label for "Exactly-Once Delivery" on the left. On the right is a "Use Case" note saying it's best for financial transactions, billing, or stateful workflows where duplicates cannot be tolerated.

​
Quick comparison

GuaranteeDelivery behaviorDuplicatesTypical use casesComplexity / Cost
At‑least‑onceMessages are delivered ≥1 times; Pub/Sub retries until acknowledgedPossibleLogging, telemetry, analytics ingestionLow to medium
Exactly‑onceGuarantees single effective processing (with deduplication/ack tracking)Eliminated (if implemented correctly)Billing, financial transactions, stateful workflowsHigh

​
Summary

  • At‑least‑once is Pub/Sub’s default: it prevents message loss but permits duplicate deliveries. Build subscribers to tolerate or remove duplicates.
  • Exactly‑once removes duplicates when you implement acknowledgement tracking and deduplication, but it raises complexity and operational cost. Use it only for workloads where duplicates are unacceptable.
We’ll also cover how Pub/Sub handles messages that repeatedly fail processing and introduce the dead letter queue (DLQ) concept next: see the dead letter topics documentation for details and configuration guidance.

Watch Video