Pub/Sub vs Cloud Tasks in GCP - Visual Side-by-Side Comparison

Process Flow - Pub/Sub vs Cloud Tasks

Event or Task Created

↓

Message Published

↓

Subscribers Receive

↓

Process Message

↓

Ack Message

↓

End of Flow

Shows how Pub/Sub and Cloud Tasks handle events and tasks differently: Pub/Sub broadcasts messages to subscribers, while Cloud Tasks schedules and manages individual tasks with retries.

Execution Sample

GCP

1. Publish message to Pub/Sub topic
2. Subscriber receives message and processes it
3. Acknowledge message

--- vs ---

1. Create task in Cloud Tasks queue
2. Task is scheduled and executed by worker
3. Task is acknowledged or retried

Compares the step-by-step flow of Pub/Sub message processing versus Cloud Tasks task execution.

Process Table

Step	Pub/Sub Action	Pub/Sub State	Cloud Tasks Action	Cloud Tasks State
1	Publish message to topic	Message in topic	Create task in queue	Task in queue
2	Message delivered to subscriber	Message pending ack	Task scheduled for execution	Task scheduled
3	Subscriber processes message	Processing	Worker executes task	Executing
4	Subscriber acknowledges message	Message removed	Task completed successfully	Task removed
5	No more messages	Idle	No pending tasks	Idle
6	N/A	N/A	If task fails, retry according to policy	Retry or dead-letter queue

💡 Flow ends when message is acknowledged in Pub/Sub or task is completed/failed in Cloud Tasks

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Pub/Sub Message	None	In topic	Delivered to subscriber	Processing	Acknowledged and removed	None
Cloud Task	None	In queue	Scheduled	Executing	Completed and removed	None

Key Moments - 3 Insights

Why does Pub/Sub deliver messages to multiple subscribers but Cloud Tasks sends each task to only one worker?

Pub/Sub is designed for broadcast messaging to many subscribers (see execution_table step 2), while Cloud Tasks manages individual tasks with exactly-once execution (see execution_table step 3).

What happens if a Cloud Task fails during execution?

Cloud Tasks retries the task based on retry policy or moves it to a dead-letter queue (see execution_table step 6), unlike Pub/Sub which relies on message acknowledgment.

Can Pub/Sub guarantee the order of message processing like Cloud Tasks?

No, Pub/Sub does not guarantee strict ordering unless using ordering keys, while Cloud Tasks can enforce order by scheduling tasks sequentially.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the Pub/Sub message acknowledged and removed?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Pub/Sub Action' and 'Pub/Sub State' columns at Step 4 in the execution_table.

According to the variable_tracker, what is the state of the Cloud Task after Step 2?

A In queue

B Scheduled

C Executing

D Completed

💡 Hint

Look at the 'Cloud Task' row under 'After Step 2' in the variable_tracker.

If a Cloud Task fails, what happens next according to the execution_table?

A Message is acknowledged and removed

B Task is retried or sent to dead-letter queue

C Task is immediately deleted

D Subscriber receives the message again

💡 Hint

See the Cloud Tasks State at Step 6 in the execution_table.

Concept Snapshot

Pub/Sub broadcasts messages to multiple subscribers asynchronously.
Cloud Tasks schedules individual tasks with guaranteed execution and retries.
Pub/Sub requires message acknowledgment; Cloud Tasks manages retries automatically.
Use Pub/Sub for event-driven messaging; use Cloud Tasks for reliable task execution.
Ordering is optional in Pub/Sub, but can be enforced in Cloud Tasks.
Both integrate with GCP services for scalable workflows.

Full Transcript

This visual execution compares Google Cloud Pub/Sub and Cloud Tasks. Pub/Sub works by publishing messages to a topic, which are then delivered to one or more subscribers. Subscribers process and acknowledge messages to remove them from the system. Cloud Tasks creates tasks in a queue, schedules them for execution by workers, and manages retries if tasks fail. The execution table shows step-by-step states for both services, highlighting differences in message delivery, processing, and completion. Variable tracking shows how messages and tasks move through states. Key moments clarify common confusions about delivery guarantees, retries, and ordering. The quiz tests understanding of these flows by referencing specific steps and states. The snapshot summarizes when to use each service and their core behaviors.

Practice

1. Which Google Cloud service is best suited for sending messages to multiple subscribers quickly and asynchronously?

easy

A. Cloud Functions

B. Cloud Tasks

C. Pub/Sub

D. Cloud Run

Solution

1. Step 1: Understand Pub/Sub's purpose

   Pub/Sub is designed to send messages to many subscribers quickly and asynchronously, enabling event-driven architectures.

2. Step 2: Compare with Cloud Tasks

   Cloud Tasks manages individual work items with control over retries and timing, not broad message delivery.

3. Final Answer:

   Pub/Sub -> Option C

4. Quick Check:

   Event broadcasting = Pub/Sub [OK]

Hint: Pub/Sub = many subscribers fast; Cloud Tasks = controlled retries [OK]

Common Mistakes:

• Confusing Cloud Tasks as a message broadcaster
• Thinking Pub/Sub controls task retries
• Mixing Cloud Functions with messaging services

2. Which of the following is the correct way to create a Cloud Task with a scheduled delay in Google Cloud?

easy

A. Use Pub/Sub with a delay attribute

B. Use Cloud Tasks client and set scheduleTime to future timestamp

C. Send a message to Pub/Sub and rely on subscriber delay

D. Create a Cloud Function with a timer trigger instead

Solution

1. Step 1: Identify scheduling method in Cloud Tasks

   Cloud Tasks allows setting a scheduleTime property to delay task execution until a future timestamp.

2. Step 2: Eliminate incorrect options

   Pub/Sub does not support scheduling messages; Cloud Functions timer triggers are separate services.

3. Final Answer:

   Use Cloud Tasks client and set scheduleTime to future timestamp -> Option B

4. Quick Check:

   Scheduled tasks = Cloud Tasks scheduleTime [OK]

Hint: Schedule tasks with Cloud Tasks scheduleTime, not Pub/Sub [OK]

Common Mistakes:

• Trying to delay Pub/Sub messages directly
• Confusing Cloud Functions timers with Cloud Tasks scheduling
• Assuming subscribers can delay message processing

3. Given the following scenario: A Cloud Task is created with maxAttempts set to 3 and a retry delay of 10 seconds. If the task fails twice, what happens next?

medium

A. The task is retried after 10 seconds delay for the third attempt

B. The task is retried immediately without delay

C. The task is discarded after the second failure

D. Pub/Sub resends the message automatically

Solution

1. Step 1: Understand Cloud Tasks retry policy

   Cloud Tasks retries failed tasks up to maxAttempts, applying the configured retry delay between attempts.

2. Step 2: Apply to given scenario

   After two failures, the third attempt will be retried after the 10 seconds delay before final failure or success.

3. Final Answer:

   The task is retried after 10 seconds delay for the third attempt -> Option A

4. Quick Check:

   Retries respect delay and maxAttempts in Cloud Tasks [OK]

Hint: Cloud Tasks retries wait delay before next try, up to maxAttempts [OK]

Common Mistakes:

• Assuming immediate retry without delay
• Thinking task is discarded too early
• Confusing Pub/Sub automatic retries with Cloud Tasks

4. You have a Cloud Task that never executes and keeps retrying indefinitely. What is the most likely cause?

medium

A. The Cloud Task queue is paused

B. Pub/Sub subscription is missing

C. The task's maxAttempts is set to 0 or unlimited

D. The task's scheduleTime is in the past

Solution

1. Step 1: Analyze retry behavior

   If a task retries indefinitely, it means it keeps failing but is still being retried.

2. Step 2: Check queue state

   If the Cloud Task queue is paused, tasks will not execute but may keep retrying or remain pending.

3. Step 3: Eliminate other options

   Pub/Sub subscription missing is unrelated to Cloud Tasks; maxAttempts 0 means no retries; scheduleTime in past triggers immediate execution.

4. Final Answer:

   The Cloud Task queue is paused -> Option A

5. Quick Check:

   Paused queue blocks task execution causing retries [OK]

Hint: Paused queue stops tasks but retries may appear stuck [OK]

Common Mistakes:

• Confusing Pub/Sub with Cloud Tasks
• Assuming maxAttempts 0 means infinite retries
• Thinking scheduleTime in past delays execution

5. You need to design a system that processes user signup events by notifying multiple services quickly, but also schedules follow-up tasks with guaranteed retries and delays. Which combination of services should you use?

hard

A. Use only Cloud Tasks for both notifications and follow-ups

B. Use only Pub/Sub with delayed message delivery

C. Use Cloud Functions triggered by HTTP for all processing

D. Use Pub/Sub for notifications and Cloud Tasks for follow-up tasks

Solution

1. Step 1: Identify service for quick multi-subscriber notifications

   Pub/Sub is ideal for sending events quickly to multiple subscribers asynchronously.

2. Step 2: Identify service for scheduled, reliable task execution

   Cloud Tasks provides control over retries, delays, and guaranteed execution for follow-up work.

3. Step 3: Combine services for best fit

   Use Pub/Sub to notify many services fast, and Cloud Tasks to manage follow-up tasks with retries and delays.

4. Final Answer:

   Use Pub/Sub for notifications and Cloud Tasks for follow-up tasks -> Option D

5. Quick Check:

   Pub/Sub for events + Cloud Tasks for reliable tasks [OK]

Hint: Combine Pub/Sub for events and Cloud Tasks for retries/delays [OK]

Common Mistakes:

• Trying to use Pub/Sub for delayed retries
• Using Cloud Tasks for broad event broadcasting
• Ignoring retry guarantees needed for follow-ups