Pull vs push subscriptions in GCP - Visual Side-by-Side Comparison

Process Flow - Pull vs push subscriptions

Message Published

↓

Message Delivered

↓

Message Published

↓

Client Pulls Message

↓

Message Delivered

Messages are sent to subscribers either by pushing to an endpoint automatically or by subscribers pulling messages when ready.

Execution Sample

GCP

1. Publish message to topic
2a. Push subscription sends message to endpoint
2b. Pull subscription waits for client to request
3. Client receives message

Shows the two ways messages reach subscribers: push sends automatically, pull waits for client request.

Process Table

Step	Action	Subscription Type	Message State	Result
1	Message published to topic	N/A	Message in topic	Message ready for delivery
2a	Push subscription receives message	Push	Message in subscription	Message sent to endpoint URL
3a	Endpoint acknowledges message	Push	Message delivered	Message removed from subscription
2b	Pull subscription receives message	Pull	Message in subscription	Message waits for client pull
3b	Client pulls message	Pull	Message delivered	Message acknowledged and removed
4	No more messages	Both	No messages	Waiting for new messages

💡 No messages left in subscription; system waits for new messages.

Status Tracker

Variable	Start	After Step 1	After Step 2a	After Step 3a	After Step 2b	After Step 3b	Final
Message State	None	In Topic	In Push Subscription	Delivered and Removed	In Pull Subscription	Delivered and Removed	None

Key Moments - 3 Insights

Why does the pull subscription keep the message until the client pulls it?

Because pull subscriptions wait for the client to request messages, the message stays in the subscription until pulled, as shown in step 2b and 3b in the execution_table.

How does the push subscription deliver messages automatically?

Push subscriptions send messages immediately to a configured endpoint URL without waiting, as seen in steps 2a and 3a in the execution_table.

What happens if the endpoint in push subscription does not acknowledge the message?

The message remains undelivered and may be retried until acknowledged, but this is outside the current table scope; the key is that acknowledgment removes the message as in step 3a.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the pull subscription deliver the message to the client?

A Step 3b

B Step 1

C Step 2a

D Step 3a

💡 Hint

Check the 'Subscription Type' and 'Result' columns for pull subscription delivery.

According to variable_tracker, what is the message state after step 3a?

A In Topic

B In Pull Subscription

C Delivered and Removed

D None

💡 Hint

Look at the 'After Step 3a' column for 'Message State'.

If the client never pulls messages in a pull subscription, what happens to the message?

A It is automatically sent to an endpoint

B It stays in the subscription waiting

C It is deleted immediately

D It is sent back to the topic

💡 Hint

Refer to step 2b and 3b in the execution_table and variable_tracker.

Concept Snapshot

Pull vs Push Subscriptions:
- Push: Messages sent automatically to endpoint URL.
- Pull: Client requests messages when ready.
- Push requires endpoint acknowledgment.
- Pull holds messages until client pulls.
- Choose based on delivery control needs.

Full Transcript

This visual execution shows how messages flow in Google Cloud Pub/Sub using pull and push subscriptions. When a message is published, push subscriptions immediately send it to a configured endpoint, which must acknowledge receipt to remove the message. Pull subscriptions keep the message until a client explicitly requests it, giving the client control over when to receive messages. The execution table traces each step, showing message states and actions. Variable tracking highlights how message state changes from being in the topic, to subscription, to delivered and removed. Key moments clarify common confusions about message delivery timing and acknowledgment. The quiz tests understanding by referencing specific steps and states in the tables.

Practice

1. What is the main difference between a pull subscription and a push subscription in Google Cloud Pub/Sub?

easy

A. Pull subscriptions send messages automatically; push subscriptions require your app to request messages.

B. Pull subscriptions are faster than push subscriptions in all cases.

C. Pull subscriptions only work with HTTP; push subscriptions only work with gRPC.

D. Pull subscriptions require your app to request messages; push subscriptions send messages automatically.

Solution

1. Step 1: Understand pull subscription behavior

   Pull subscriptions require the client application to ask for messages explicitly.

2. Step 2: Understand push subscription behavior

   Push subscriptions automatically send messages to the client via HTTP POST.

3. Final Answer:

   Pull subscriptions require your app to request messages; push subscriptions send messages automatically. -> Option D

4. Quick Check:

   Pull = request, Push = automatic [OK]

Hint: Pull means ask; push means receive automatically [OK]

Common Mistakes:

• Confusing which subscription type initiates message delivery
• Thinking push requires app to poll for messages
• Assuming pull subscriptions send messages automatically

2. Which of the following is the correct way to configure a push subscription endpoint URL in Google Cloud Pub/Sub?

easy

A. Set the subscription's pushConfig with a valid HTTPS URL where messages will be sent.

B. Set the subscription's pullConfig with the endpoint URL to pull messages.

C. Configure the subscription with a TCP socket address for push delivery.

D. Use the subscription's pushConfig with an FTP URL for message delivery.

Solution

1. Step 1: Identify correct pushConfig usage

   Push subscriptions require setting pushConfig with a valid HTTPS URL for message delivery.

2. Step 2: Eliminate incorrect options

   PullConfig does not exist; TCP and FTP are not supported protocols for push endpoints.

3. Final Answer:

   Set the subscription's pushConfig with a valid HTTPS URL where messages will be sent. -> Option A

4. Quick Check:

   PushConfig needs HTTPS URL [OK]

Hint: Push subscriptions need HTTPS URL in pushConfig [OK]

Common Mistakes:

• Using pullConfig instead of pushConfig
• Setting non-HTTPS URLs for push endpoints
• Confusing pull and push subscription settings

3. Consider this code snippet for a pull subscription client in Python using Google Cloud Pub/Sub:

from google.cloud import pubsub_v1
subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path('my-project', 'my-sub')
response = subscriber.pull(subscription=subscription_path, max_messages=1)
print(len(response.received_messages))

What will this code print if there is exactly one message available in the subscription?

medium

A. Error due to missing ack

B. 0

C. 1

D. None

Solution

1. Step 1: Understand pull method behavior

   The pull method requests messages; if one message is available, it returns it in received_messages.

2. Step 2: Check printed output

   len(response.received_messages) will be 1 because exactly one message is pulled.

3. Final Answer:

   1 -> Option C

4. Quick Check:

   One message pulled means length is 1 [OK]

Hint: Pull returns messages list; length matches available messages [OK]

Common Mistakes:

• Assuming pull returns zero without ack
• Expecting error if ack is missing
• Confusing pull with push subscription behavior

4. You have a push subscription configured, but your app is not receiving any messages. Which of the following is the most likely cause?

medium

A. The push endpoint URL is incorrect or unreachable.

B. The subscription is set to pull instead of push.

C. The app forgot to call pull() method.

D. The topic has no messages published.

Solution

1. Step 1: Check push subscription delivery requirements

   Push subscriptions require a reachable, correct HTTPS endpoint to deliver messages.

2. Step 2: Analyze other options

   Pull vs push setting is fixed; pull() is not used in push; no messages means no delivery but question implies messages exist.

3. Final Answer:

   The push endpoint URL is incorrect or unreachable. -> Option A

4. Quick Check:

   Push needs correct reachable URL [OK]

Hint: Push needs reachable endpoint URL [OK]

Common Mistakes:

• Confusing pull and push subscription methods
• Assuming pull() is needed for push subscriptions
• Ignoring network or URL errors

5. You want to design a system that processes messages only when your app is ready and can control the rate of message processing. Which subscription type should you choose and why?

hard

A. Push subscription, because it retries sending messages until acknowledged.

B. Pull subscription, because your app controls when to request messages.

C. Push subscription, because messages are sent automatically and fast.

D. Pull subscription, because it automatically scales message delivery.

Solution

1. Step 1: Identify control needs

   The app wants to control when and how fast messages are processed.

2. Step 2: Match subscription type to control

   Pull subscriptions let the app ask for messages when ready, controlling rate and timing.

3. Final Answer:

   Pull subscription, because your app controls when to request messages. -> Option B

4. Quick Check:

   Pull = app controls message flow [OK]

Hint: Choose pull to control message processing timing [OK]

Common Mistakes:

• Choosing push for control over message rate
• Assuming push retries mean better control
• Thinking pull auto-scales delivery