Pub/Sub vs Cloud Tasks in GCP - Performance Comparison
We want to understand how the number of operations grows when using Pub/Sub or Cloud Tasks for handling messages.
Which service scales better as the number of messages increases?
Analyze the time complexity of publishing and processing messages using Pub/Sub and Cloud Tasks.
// Pub/Sub example
for (int i = 0; i < n; i++) {
pubsub.publish(topic, message);
}
// Cloud Tasks example
for (int i = 0; i < n; i++) {
cloudTasks.createTask(queue, taskPayload);
}
This sequence sends n messages either by publishing to a Pub/Sub topic or creating tasks in a Cloud Tasks queue.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Publishing a message to Pub/Sub or creating a task in Cloud Tasks.
- How many times: Exactly n times, once per message.
Each message requires one API call, so the total calls grow directly with the number of messages.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 calls |
| 100 | 100 calls |
| 1000 | 1000 calls |
Pattern observation: The number of operations grows linearly as the number of messages increases.
Time Complexity: O(n)
This means the time to send or create messages grows directly in proportion to how many messages you have.
[X] Wrong: "Sending many messages is just one operation regardless of count."
[OK] Correct: Each message requires its own API call, so the total work grows with the number of messages, not stays the same.
Understanding how message volume affects API calls helps you design systems that scale well and choose the right service for your needs.
"What if we batch messages before sending? How would the time complexity change?"
Practice
Solution
Step 1: Understand Pub/Sub's purpose
Pub/Sub is designed to send messages to many subscribers quickly and asynchronously, enabling event-driven architectures.Step 2: Compare with Cloud Tasks
Cloud Tasks manages individual work items with control over retries and timing, not broad message delivery.Final Answer:
Pub/Sub -> Option CQuick Check:
Event broadcasting = Pub/Sub [OK]
- Confusing Cloud Tasks as a message broadcaster
- Thinking Pub/Sub controls task retries
- Mixing Cloud Functions with messaging services
Solution
Step 1: Identify scheduling method in Cloud Tasks
Cloud Tasks allows setting a scheduleTime property to delay task execution until a future timestamp.Step 2: Eliminate incorrect options
Pub/Sub does not support scheduling messages; Cloud Functions timer triggers are separate services.Final Answer:
Use Cloud Tasks client and set scheduleTime to future timestamp -> Option BQuick Check:
Scheduled tasks = Cloud Tasks scheduleTime [OK]
- Trying to delay Pub/Sub messages directly
- Confusing Cloud Functions timers with Cloud Tasks scheduling
- Assuming subscribers can delay message processing
Solution
Step 1: Understand Cloud Tasks retry policy
Cloud Tasks retries failed tasks up to maxAttempts, applying the configured retry delay between attempts.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.Final Answer:
The task is retried after 10 seconds delay for the third attempt -> Option AQuick Check:
Retries respect delay and maxAttempts in Cloud Tasks [OK]
- Assuming immediate retry without delay
- Thinking task is discarded too early
- Confusing Pub/Sub automatic retries with Cloud Tasks
Solution
Step 1: Analyze retry behavior
If a task retries indefinitely, it means it keeps failing but is still being retried.Step 2: Check queue state
If the Cloud Task queue is paused, tasks will not execute but may keep retrying or remain pending.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.Final Answer:
The Cloud Task queue is paused -> Option AQuick Check:
Paused queue blocks task execution causing retries [OK]
- Confusing Pub/Sub with Cloud Tasks
- Assuming maxAttempts 0 means infinite retries
- Thinking scheduleTime in past delays execution
Solution
Step 1: Identify service for quick multi-subscriber notifications
Pub/Sub is ideal for sending events quickly to multiple subscribers asynchronously.Step 2: Identify service for scheduled, reliable task execution
Cloud Tasks provides control over retries, delays, and guaranteed execution for follow-up work.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.Final Answer:
Use Pub/Sub for notifications and Cloud Tasks for follow-up tasks -> Option DQuick Check:
Pub/Sub for events + Cloud Tasks for reliable tasks [OK]
- Trying to use Pub/Sub for delayed retries
- Using Cloud Tasks for broad event broadcasting
- Ignoring retry guarantees needed for follow-ups
Ready to prove it?
Pass the test and this pattern moves unknown
