Push vs Pull Subscriptions

Google Cloud Pub/Sub supports two primary delivery mechanisms for messages: pull and push subscriptions. Choosing the right delivery mode is a critical architectural decision that affects latency, scalability, cost, and operational complexity. This lesson covers both modes in depth, comparing their characteristics and providing guidance on when to use each.

---

Pull Subscriptions

With a pull subscription, the subscriber actively requests messages from Pub/Sub. The subscriber calls the pull API (or uses streaming pull) and Pub/Sub returns available messages. The subscriber processes each message and sends an acknowledgement.

How Pull Works

1. The subscriber opens a connection to Pub/Sub
2. The subscriber calls Pull or StreamingPull to request messages
3. Pub/Sub returns available messages (up to the configured limit)
4. The subscriber processes each message
5. The subscriber sends an Acknowledge request for each successfully processed message
6. If the subscriber does not acknowledge within the deadline, Pub/Sub redelivers the message

Streaming Pull vs Unary Pull

Feature	Streaming Pull	Unary Pull
Connection	Long-lived bidirectional gRPC stream	Short-lived request-response
Latency	Low — messages delivered as they arrive	Higher — must poll periodically
Throughput	High — continuous flow of messages	Lower — limited by poll frequency
Complexity	More complex (connection management)	Simpler to implement
Recommended	Yes — used by all client libraries	Only for simple scripts

The official Google Cloud client libraries use streaming pull by default. This opens a long-lived gRPC connection and receives messages as they are published, providing near-real-time delivery with high throughput.

Pull Subscriber Example (Python)

from google.cloud import pubsub_v1

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

def callback(message):
    print(f"Received: {message.data.decode()}")
    message.ack()

streaming_pull_future = subscriber.subscribe(subscription_path, callback=callback)
print(f"Listening on {subscription_path}...")

try:
    streaming_pull_future.result()
except KeyboardInterrupt:
    streaming_pull_future.cancel()
    streaming_pull_future.result()

Pull Subscriber Example (Node.js)

const { PubSub } = require("@google-cloud/pubsub");
const pubsub = new PubSub();

const subscription = pubsub.subscription("my-sub");

subscription.on("message", (message) => {
  console.log("Received:", message.data.toString());
  message.ack();
});

subscription.on("error", (error) => {
  console.error("Error:", error);
});

Acknowledgement Deadline

The acknowledgement deadline is the time a subscriber has to process and acknowledge a message before Pub/Sub redelivers it. The default is 10 seconds, but you can configure it from 10 to 600 seconds.

# Set ack deadline to 120 seconds
gcloud pubsub subscriptions update my-sub --ack-deadline=120

Client libraries also support deadline extension (modifyAckDeadline), which automatically extends the deadline while the message is being processed. This prevents redelivery of messages that take longer than the configured deadline.

---

Push Subscriptions

With a push subscription, Pub/Sub sends messages to a subscriber endpoint via HTTPS POST requests. The subscriber does not need to poll — Pub/Sub proactively delivers messages as they arrive.

How Push Works

1. A message is published to the topic
2. Pub/Sub sends an HTTPS POST request to the push endpoint with the message in the body
3. The subscriber processes the message
4. The subscriber returns an HTTP success response (2xx) to acknowledge the message
5. If the endpoint returns an error or does not respond, Pub/Sub retries with exponential backoff

Push Endpoint Requirements

• Must be a publicly reachable HTTPS URL (or a VPC Service Controls endpoint)
• Must respond within the acknowledgement deadline
• Must return a 2xx status code to acknowledge
• Can use authentication via OIDC tokens from a service account

Push Authentication