Cloud PubSub Acknowledgement

​

Message lifecycle and where acknowledgements fit

1. A topic is created and publishers send messages to it.
2. A subscription is created for the topic; subscribers either pull messages or receive pushed messages from the subscription.
3. Pub/Sub delivers a message to the subscriber (push or pull).
4. The subscriber must acknowledge the message to signal successful processing.
5. If Pub/Sub does not receive an ack before the ack deadline expires, or if the subscriber explicitly nacks the message, the message becomes eligible for redelivery.

​

Key implementation details

​

Acknowledgement types and behaviors

​

Practical examples (Python client library)

from google.cloud import pubsub_v1

subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path("my-project", "my-subscription")

# Pull messages
response = subscriber.pull(subscription=subscription_path, max_messages=1)

for received in response.received_messages:
    data = received.message.data
    print("Received:", data)
    ack_id = received.ack_id

    # Acknowledge the message so it won't be redelivered
    subscriber.acknowledge(subscription=subscription_path, ack_ids=[ack_id])

# Extend the ack deadline for this ack_id to 60 seconds
subscriber.modify_ack_deadline(
    subscription=subscription_path,
    ack_ids=[ack_id],
    ack_deadline_seconds=60,
)

from google.cloud import pubsub_v1

subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path("my-project", "my-subscription")

def callback(message):
    print("Received:", message.data)
    try:
        # Process the message...
        message.ack()  # Explicit acknowledgement
    except Exception:
        # Signal failure; many client libraries support message.nack()
        message.nack()

subscriber.subscribe(subscription_path, callback=callback)

# Keep the main thread alive to allow background threads to process messages
import time
while True:
    time.sleep(60)

​

Notes on system design and subscriber behavior

• Subscriber processing times vary. For short, predictable tasks, short ack deadlines may suffice. For long-running tasks, extend the ack deadline per message or increase the subscription default.
• At-least-once delivery requires idempotency or deduplication. If your processing can’t be made idempotent, use dedupe strategies (unique message IDs, external dedupe stores, etc.).
• For push endpoints, only return HTTP 2xx when processing actually succeeded. Returning 2xx will stop retries and is treated as an acknowledgement by Pub/Sub.
• Use modifyAckDeadline() responsibly to avoid holding messages indefinitely and to ensure fair redelivery behavior.

​

Quick exam pointers

• Pub/Sub uses ack IDs and ack deadlines to manage delivery and retries.
• The typical exam concept is “at-least-once delivery”: messages may be delivered more than once unless you implement deduplication or enable exactly-once features where supported.

​

Links and references

• Pub/Sub documentation - Subscriber best practices
• Pub/Sub Python client library