This chapter covers Google Cloud Pub/Sub push and pull subscriptions, a core topic for the Associate Cloud Engineer exam. Understanding the differences between these two delivery models is critical for designing reliable, scalable messaging systems. Approximately 5-8% of exam questions touch on Pub/Sub concepts, with push vs pull being a frequent differentiator. You will learn the internal mechanics, configuration steps, and when to choose each mode.
Jump to a section
Imagine a busy restaurant kitchen. The chef (publisher) prepares dishes and places them on a counter (topic). There are two ways waiters (subscribers) can get orders. In the push model, the chef actively calls out each finished dish and hands it directly to a waiter who is standing by. The chef must know which waiter wants which dish, and if no waiter is present, the dish sits and gets cold (message loss). In the pull model, waiters periodically check the counter for orders they are assigned to handle. They ask the expediter (subscription) for any pending dishes. If a waiter is busy, the dish waits on the counter (message storage). The chef never has to track waiters; they just put dishes on the counter. In Google Pub/Sub, push subscriptions require a pre-configured endpoint URL that receives HTTP POST requests from Pub/Sub. The service pushes messages as soon as they are available. If the endpoint is down, messages are retried with exponential backoff up to a maximum of 7 days. Pull subscriptions require the subscriber to call the synchronous pull method to retrieve messages. The subscriber can control the flow and batch size. This analogy mirrors the mechanism: push is event-driven with immediate delivery, pull is poll-driven with client-controlled pacing. The key difference is who initiates the transfer: the server (push) or the client (pull).
What is Pub/Sub and Why Subscriptions Matter
Google Cloud Pub/Sub is an asynchronous messaging service that decouples message producers (publishers) from message consumers (subscribers). A topic is a named resource to which publishers send messages. A subscription is a named resource that represents the stream of messages from a single topic to be delivered to a subscribing application. The subscription defines the delivery method: push or pull. The choice affects reliability, latency, cost, and system architecture.
Push Subscription Mechanics
In a push subscription, Pub/Sub sends each message as an HTTP POST request to a pre-configured endpoint URL. The endpoint must be a publicly accessible HTTPS endpoint (HTTP is not supported for security). The request body contains the message data and attributes in JSON format. The endpoint must acknowledge receipt by returning an HTTP 200 (or 201, 204) status code within a timeout period (default 10 seconds, configurable up to 600 seconds). If the endpoint returns any other status code, times out, or is unreachable, Pub/Sub retries the message with exponential backoff. The retry policy has a maximum delivery duration of 7 days (configurable). After that, messages are dropped or forwarded to a dead letter topic if configured.
The push endpoint URL must be configured when creating the subscription. It can be a Cloud Function, App Engine service, Cloud Run, or any external HTTPS server. Pub/Sub uses the subscription's service account to authenticate the push request, typically by attaching an OAuth 2.0 token in the Authorization header. The endpoint must validate the token to ensure the request is from Pub/Sub.
Pull Subscription Mechanics
In a pull subscription, the subscriber client initiates requests to retrieve messages. There are two pull methods: synchronous pull and asynchronous pull (via the streaming pull API). Synchronous pull uses the subscriptions.pull method, where the client specifies the maximum number of messages to return (maxMessages, default 1, maximum 1000) and returns immediately or after a short timeout (returnImmediately flag). Asynchronous pull uses the streaming pull API, which establishes a long-lived bidirectional gRPC stream for high-throughput message delivery. The client receives messages as they become available without polling overhead.
When a message is pulled, the subscriber must acknowledge it within a configurable acknowledgement deadline (default 10 seconds, minimum 10, maximum 600). The ack deadline can be modified per message using modifyAckDeadline. If the deadline expires before acknowledgment, the message becomes available for redelivery. The subscriber can also negatively acknowledge (nack) a message, which immediately makes it available for redelivery. Pull subscriptions support flow control: the subscriber can limit the number of outstanding messages to prevent overload.
Key Differences and Defaults
Delivery initiation: Push is server-initiated; pull is client-initiated.
Endpoint requirement: Push requires a public HTTPS endpoint; pull requires a client that can make outbound requests to Pub/Sub (no inbound firewall needed).
Acknowledgement: Both require ack within a deadline. For push, ack is implicit on HTTP 200. For pull, ack is explicit via acknowledge method.
Retry: Push has built-in retry with exponential backoff. Pull retries are controlled by the subscriber (by not acking or nacking).
Latency: Push delivers immediately (low latency). Pull introduces polling latency (synchronous) or near-real-time (streaming pull).
Flow control: Push has no client-side flow control; the server delivers as fast as the endpoint can ack. Pull allows client-side flow control.
Authentication: Push uses OAuth tokens; pull uses service account credentials with pubsub.subscriber role.
Dead letter queues: Both support dead letter topics for undeliverable messages after max retries.
Ordering: Both support message ordering if the subscription is created with enable_message_ordering=true and messages have ordering keys.
Configuration and Commands
To create a push subscription using gcloud:
gcloud pubsub subscriptions create my-push-sub --topic=my-topic --push-endpoint=https://myendpoint.example.com/push --ack-deadline=30To create a pull subscription:
gcloud pubsub subscriptions create my-pull-sub --topic=my-topic --ack-deadline=60To pull messages:
gcloud pubsub subscriptions pull my-pull-sub --auto-ack --limit=10Interaction with Related Technologies
Pub/Sub push subscriptions are commonly used with Cloud Functions (HTTP triggers), App Engine, Cloud Run, and external services. Pull subscriptions are used with Compute Engine VMs, Kubernetes pods, or any custom application that can use the Pub/Sub client libraries. Cloud Scheduler can trigger Pub/Sub topics, which then push to endpoints. Dataflow can read from pull subscriptions using a streaming source. Push subscriptions can also be used with Webhook endpoints, but must handle authentication and retries.
Dead Letter Queues
Both push and pull subscriptions can be configured with a dead letter topic. After a configurable number of delivery attempts (default 5, min 5, max 100), undelivered messages are forwarded to the dead letter topic. The dead letter topic must be in the same project or a different project (requires permissions). This prevents message loss and allows offline analysis of failed messages.
Filtering
Subscriptions can have a filter expression to select only certain messages based on attributes. Filtering reduces unnecessary deliveries and costs. Filters are applied before delivery, so push endpoints only receive matching messages, and pull clients only see matching messages.
Retry Policy
For push subscriptions, the retry policy is defined by the subscription's retry_policy which sets minimum and maximum backoff durations (default: min 10 seconds, max 600 seconds). For pull subscriptions, retry is implicit; the subscriber must handle retries by not acking.
Monitoring
Cloud Monitoring provides metrics for both types: pubsub.googleapis.com/subscription/push_request_count, pubsub.googleapis.com/subscription/ack_message_count, pubsub.googleapis.com/subscription/backlog_bytes. Alerts can be set for high backlog or high undelivered message rates.
Exam Focus
The ACE exam tests the ability to choose between push and pull based on requirements. Key points: push requires a public HTTPS endpoint; pull is for private VPC resources. Push has built-in retry; pull requires client-side ack. Streaming pull is for high throughput. Dead letter topics are for handling failures. Filters reduce cost. Ack deadline must be appropriate for processing time.
Common Pitfalls
Using HTTP instead of HTTPS for push (will fail).
Setting ack deadline too short for processing time (causes redelivery).
Not configuring authentication for push endpoints (unverified requests).
Using synchronous pull with returnImmediately=true in a loop (inefficient).
Forgetting to ack messages in pull (causes redelivery and backlog).
Performance Considerations
Push subscriptions can handle thousands of messages per second per endpoint, but the endpoint must be scalable. Pull subscriptions with streaming pull can handle millions of messages per second across multiple subscribers. Flow control in pull prevents subscriber overload. Batching in push (via maxMessages in the push config) can improve efficiency.
Security
Push endpoints must use HTTPS. The push request includes an OAuth token that the endpoint should verify using Google's public keys. The token's audience is the push endpoint URL. Pull subscriptions use service account credentials with IAM roles. The pubsub.subscriber role allows pulling and acking. The pubsub.viewer role allows only pulling without acking.
Summary
Push subscriptions are ideal for serverless endpoints and low-latency event-driven architectures. Pull subscriptions are better for batch processing, private VPC resources, and when the subscriber needs to control message flow. The choice depends on the consumer's ability to receive inbound requests and the need for client-side flow control.
Create a Topic
First, create a topic that will receive messages from publishers. Use `gcloud pubsub topics create my-topic`. The topic is a named resource; messages sent to it are retained for up to 7 days (default) or a configurable retention duration. The topic is the central hub; subscriptions attach to it.
Create a Push Subscription
Create a push subscription with `gcloud pubsub subscriptions create my-push-sub --topic=my-topic --push-endpoint=https://example.com/push`. The endpoint must be HTTPS. Pub/Sub will POST messages to this URL. Set the ack deadline (default 10s) based on expected processing time. Optionally configure retry policy and dead letter topic.
Create a Pull Subscription
Create a pull subscription with `gcloud pubsub subscriptions create my-pull-sub --topic=my-topic`. No endpoint is needed. The subscriber will pull messages using the client library or gcloud. Set the ack deadline appropriately. For high throughput, enable streaming pull.
Publish Messages
Publish messages to the topic using `gcloud pubsub topics publish my-topic --message='Hello'`. Messages are immediately available to all subscriptions. For push, Pub/Sub attempts delivery immediately. For pull, messages wait until a subscriber pulls them.
Acknowledge Messages
For push, ack is automatic on HTTP 200. For pull, the subscriber must call `acknowledge` with the ack IDs. Use `gcloud pubsub subscriptions pull my-pull-sub --auto-ack` to pull and ack in one command. If not acked within deadline, message is redelivered. Use `modifyAckDeadline` to extend processing time.
In a real-world e-commerce platform, push subscriptions are used to trigger order fulfillment workflows. When a customer places an order, the order service publishes a message to an 'orders' topic. A push subscription sends the message to a Cloud Function that processes payment, updates inventory, and sends confirmation emails. The push model ensures low latency (sub-second) and automatic retries if the function fails. The function must scale to handle peak loads like Black Friday; Cloud Functions auto-scales, but the push endpoint must be able to handle concurrent requests. Misconfiguration: if the function returns a non-200 status due to a bug, Pub/Sub retries indefinitely (up to 7 days), causing duplicate processing unless idempotency is implemented. A dead letter topic captures messages after 5 retries for manual inspection.
In a financial analytics pipeline, a pull subscription is used to batch process transaction logs from a topic. A Compute Engine VM runs a batch job every hour that pulls all unacknowledged messages (max 1000 per pull) and processes them offline. The pull model allows the VM to control the rate of processing and avoid overwhelming the database. The VM runs in a private VPC with no inbound internet access, making push impossible. Streaming pull is not used because the job is batch-oriented. Common issue: if the ack deadline is set too short (e.g., 10 seconds) and processing takes longer, messages are redelivered and processed twice. Solution: increase ack deadline to 600 seconds or use modifyAckDeadline to extend dynamically.
In a IoT telemetry system, devices send sensor readings to a topic. A push subscription sends data to a Cloud Run service that stores readings in BigQuery. Push is chosen because devices cannot poll (they only send data). The Cloud Run service must handle spikes; if it scales to zero, messages may be retried until a new instance starts. Configuration: set retry policy with min backoff 1s and max 60s to reduce latency during cold starts. Dead letter topic captures malformed messages. Performance: with 10,000 devices sending every minute, the push endpoint receives ~167 messages/second; Cloud Run can handle this with proper concurrency settings.
In a multi-region disaster recovery scenario, a pull subscription in a secondary region pulls messages from a global topic. This ensures that if the primary region fails, the secondary can process backlog. Push subscriptions are tied to a specific endpoint URL, which is region-specific, so they are less suitable for multi-region failover. Pull subscriptions allow the subscriber to be anywhere.
The ACE exam (objective 3.3) tests your ability to differentiate between push and pull subscriptions and choose the correct one based on scenario requirements. Common exam scenarios:
Scenario: An application runs in a private VPC with no public endpoint. Which subscription type? Answer: Pull, because push requires a public HTTPS endpoint.
Scenario: A serverless application needs to process messages as soon as they arrive with minimal latency. Which subscription type? Answer: Push, because it delivers immediately without polling.
Scenario: A batch job needs to process messages at its own pace and control the number of messages processed concurrently. Which subscription type? Answer: Pull, because it allows flow control and batch pulling.
Scenario: An application needs to ensure messages are not lost even if the subscriber is down for hours. Which feature? Answer: Use a pull subscription with a long ack deadline, or configure a dead letter topic. Push subscriptions retry for up to 7 days by default.
Common wrong answers:
Choosing push for a private VPC resource (candidates forget push needs public endpoint).
Choosing pull when low latency is critical (candidates think pull is always better).
Thinking push is more reliable than pull (both are reliable; push has built-in retries, pull requires client-side ack).
Confusing ack deadline with message retention (retention is how long messages are kept in the subscription; ack deadline is time to ack).
Specific numbers:
Default ack deadline: 10 seconds.
Minimum ack deadline: 10 seconds.
Maximum ack deadline: 600 seconds.
Default message retention: 7 days (max 7 days, min 10 minutes).
Default push retry min backoff: 10 seconds, max 600 seconds.
Default dead letter max delivery attempts: 5.
Maximum pull messages per request: 1000.
Push endpoint must be HTTPS (port 443).
Edge cases:
If a push endpoint returns 429 (Too Many Requests), Pub/Sub respects the Retry-After header if present; otherwise uses exponential backoff.
If a push endpoint is unreachable, Pub/Sub retries for up to 7 days unless a dead letter topic is configured.
Streaming pull uses a single gRPC stream; if the stream breaks, the client must reconnect.
Message ordering is only guaranteed if enable_message_ordering is set on the subscription and messages have ordering keys.
How to eliminate wrong answers:
If the scenario mentions 'no public endpoint' or 'private network', eliminate push.
If the scenario mentions 'low latency' or 'real-time', eliminate synchronous pull (use push or streaming pull).
If the scenario mentions 'batch processing' or 'control pace', eliminate push.
If the scenario mentions 'serverless' or 'Cloud Function', push is likely correct.
If the scenario mentions 'multiple subscribers', both can have multiple subscriptions, but each subscription delivers to one subscriber (unless using fan-out with multiple subscriptions).
Push subscriptions deliver messages via HTTP POST to a public HTTPS endpoint; pull subscriptions require the client to retrieve messages.
Push has built-in retry with exponential backoff (default min 10s, max 600s) and a maximum delivery duration of 7 days.
Pull subscriptions support flow control; the subscriber can limit the number of outstanding messages using maxMessages.
Streaming pull (gRPC) provides low latency similar to push without polling overhead.
Default ack deadline is 10 seconds; minimum 10, maximum 600 seconds.
Dead letter topics capture messages after a configurable number of delivery attempts (default 5) for both push and pull.
Push endpoints must be HTTPS and must return HTTP 200-204 to acknowledge messages.
Pull subscriptions are required for subscribers in private VPCs without public endpoints.
Message ordering requires enable_message_ordering on the subscription and ordering keys on messages.
Filters on subscriptions reduce delivery costs by only delivering matching messages.
These come up on the exam all the time. Here's how to tell them apart.
Push Subscription
Server initiates delivery via HTTP POST to a public HTTPS endpoint.
Low latency: messages delivered immediately as they arrive.
Built-in retry with exponential backoff up to 7 days.
No client-side flow control; server pushes as fast as endpoint can ack.
Requires publicly accessible endpoint; not suitable for private VPC resources.
Pull Subscription
Client initiates retrieval via synchronous pull or streaming pull (gRPC).
Latency depends on polling frequency; streaming pull provides near-real-time.
Retry is client-controlled: subscriber must not ack or nack to trigger redelivery.
Client-side flow control: subscriber can limit outstanding messages.
Works in private VPCs with no inbound internet; client only needs outbound access to Pub/Sub API.
Mistake
Push subscriptions are more reliable than pull subscriptions because they automatically retry.
Correct
Both are reliable. Push has built-in retry with exponential backoff up to 7 days. Pull requires the subscriber to acknowledge messages; if not acknowledged, they are redelivered. Reliability depends on proper ack handling, not the delivery method.
Mistake
Pull subscriptions always have higher latency because the client must poll.
Correct
Streaming pull uses a long-lived gRPC stream that delivers messages with near-real-time latency, similar to push. Synchronous pull with `returnImmediately=false` also reduces latency. Push is not inherently lower latency if streaming pull is used.
Mistake
Push subscriptions require the endpoint to be a Google Cloud service.
Correct
The endpoint can be any publicly accessible HTTPS endpoint, including external services. However, the endpoint must be able to handle OAuth authentication.
Mistake
You cannot use pull subscriptions with Cloud Functions.
Correct
Cloud Functions can be triggered by Pub/Sub via push subscriptions (HTTP trigger) or via background functions (legacy). Pull subscriptions are not directly supported by Cloud Functions; they require a custom client.
Mistake
The ack deadline is the time a message is retained in the subscription.
Correct
The ack deadline is the time the subscriber has to acknowledge the message after delivery. Message retention is separate and configurable (default 7 days). If not acked within the deadline, the message becomes available for redelivery but remains in the subscription until the retention period expires.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Push subscriptions require HTTPS (port 443). HTTP endpoints are not supported for security reasons. If you try to create a push subscription with an HTTP URL, the creation will fail. Always use HTTPS.
Pub/Sub considers this a delivery failure and will retry the message. The retry uses exponential backoff with configurable minimum and maximum backoff durations (default 10s to 600s). After the maximum delivery duration (default 7 days), the message is dropped or sent to a dead letter topic if configured.
You must call the `acknowledge` method with the ack IDs obtained from the pull response. Using the gcloud CLI, you can use `gcloud pubsub subscriptions pull my-sub --auto-ack` to automatically ack. In client libraries, you call `subscriber.acknowledge()` or use the streaming pull callback that acks automatically.
Synchronous pull uses the `subscriptions.pull` REST API method, which returns immediately (or after a timeout) with up to maxMessages messages. Streaming pull uses a long-lived bidirectional gRPC stream that delivers messages as they become available, providing lower latency and higher throughput. Streaming pull is recommended for production high-throughput scenarios.
No. The delivery type is set at creation time. To switch, you must delete the subscription and create a new one with the desired type. However, you can update the push endpoint URL or ack deadline on an existing push subscription.
Pub/Sub includes an OAuth 2.0 token in the Authorization header of the push request. The token's audience is the push endpoint URL. The endpoint must verify the token using Google's public keys (available at https://www.googleapis.com/oauth2/v3/certs). The token is from a Google service account that has the `pubsub.subscriber` role. You can also use the `push-no-auth` option for testing (not recommended for production).
The maximum message size is 10 MB before base64 encoding. After encoding, the maximum size is approximately 13.6 MB. This applies to both push and pull subscriptions.
You've just covered Pub/Sub Push vs Pull Subscriptions — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?