Cloud PubSub PullPush methods

• How push subscriptions deliver messages to HTTPS endpoints
• How pull subscriptions let clients fetch messages (synchronously or via streaming)
• When to choose each approach, with practical examples and a decision guide

​

Push subscriptions

• Delivery: Pub/Sub sends each message to the subscriber endpoint as an HTTPS POST containing the message and attributes.
• Acknowledgement: The subscriber must return an HTTP 2xx response to acknowledge receipt. Non-2xx responses or network errors trigger retries with exponential backoff until the message is acknowledged or the message retention / dead-letter policy takes effect.
• Low latency: Because Pub/Sub actively pushes messages, push subscriptions are well suited for real-time use cases such as fraud detection, notifications, or IoT scenarios that need immediate reaction.
• Simplified client logic: The subscriber does not poll for messages; delivery, retry mechanics, and basic flow control are managed by Pub/Sub.

{
  "message": {
    "data": "BASE64_ENCODED_PAYLOAD",
    "attributes": {
      "key": "value"
    },
    "messageId": "2070443601311540",
    "publishTime": "2020-04-22T23:11:55.123Z"
  },
  "subscription": "projects/myproject/subscriptions/mysub"
}

• The data field is base64 encoded; your subscriber must decode it.
• To acknowledge the message, return an HTTP 200 OK (or any 2xx) response.

• Your application requires near-instant processing of individual messages.
• You can host a reliable HTTPS endpoint (or use Cloud Run/App Engine) that can scale or handle retries.
• You prefer simplified subscriber logic and offloaded retry handling.

​

Pull subscriptions

• Synchronous Pull API: the client issues Pull requests to fetch messages.
• StreamingPull: a long-lived gRPC stream that delivers messages to the client, improving throughput and latency for high-volume consumers.

• Client-driven: The subscriber controls when and how many messages to fetch, and must explicitly acknowledge messages using the Ack API.
• Ack deadline: Messages must be acknowledged within the ack deadline (default 10s); otherwise the message becomes available for redelivery. Subscribers can call ModifyAckDeadline to extend processing time.
• Batch- and throughput-friendly: Pull is ideal when you want to batch-process large volumes of messages at controlled rates — for example, periodic ingestion into BigQuery or feeding Dataflow pipelines.
• Flexible scaling: You can scale worker instances up or down to match processing capacity; pull gives you finer control over parallelism and batching behavior.

{
  "maxMessages": 10
}

{
  "ackIds": ["ACK_ID_1", "ACK_ID_2"]
}

• You process messages in batches or at scheduled intervals (e.g., 15-minute or hourly batches).
• You need explicit control over concurrency, rate limiting, or ack timing.
• You integrate with batch-oriented systems or worker pools that coordinate parallel processing.

​

Feature comparison

​

Quick decision guide

• Need instant, per-message processing? Choose push.
• Processing in near real-time batches or large-volume batch jobs? Choose pull (StreamingPull for high throughput).
• Want simplified subscriber code and managed retries? Push is simpler.
• Need fine-grained control over batching, concurrency, and ack deadlines? Use pull.