Pub/Sub vs Cloud Tasks in GCP: Differences and When to Use Each

Simple explanation

Pub/Sub is for broadcasting. Cloud Tasks is for controlled delegation.

How Pub/Sub works

Pub/Sub is a fully managed publish-subscribe messaging service. Publishers send messages to a topic. One or more subscriptions attached to that topic each receive a copy of every message. This is fan-out: one message in, multiple independent deliveries out.

Key concepts:

• Topics and subscriptions. A topic is a named channel. Subscriptions are independent consumers attached to a topic. Each subscription gets every message, and subscribers within a subscription compete for messages (load balancing).
• Decoupling. The publisher does not know how many subscriptions exist or what they do. You can add a new subscriber without touching the publishing service. This is the foundation of event-driven architectures.
• At-least-once delivery. By default, Pub/Sub may deliver a message more than once. Subscribers must handle duplicates. An exactly-once delivery mode is available on pull subscriptions, but it adds latency and only works when subscribers connect to the same region as the subscription.
• Delivery modes. Pub/Sub supports both push and pull delivery. Push sends messages to an HTTP endpoint. Pull lets your application fetch messages on its own schedule.
• Ordering keys. Optional. Messages with the same ordering key are delivered in publish order. Messages with different keys have no ordering guarantee.
• Scale. Pub/Sub handles millions of messages per second without provisioning.

Typical architectures: decoupled microservices where multiple services react to the same event, streaming data into data pipelines via Dataflow, triggering Cloud Run or Cloud Functions services via push subscriptions, and feeding analytics systems with real-time event data.

# Publish a message to a topic
gcloud pubsub topics publish my-topic \
  --message '{"event": "order.created", "order_id": "ord_001"}'

# Create a push subscription that delivers to a Cloud Run service
gcloud pubsub subscriptions create my-sub \
  --topic my-topic \
  --push-endpoint https://my-service-abc123-uc.a.run.app/events \
  --ack-deadline 60

How Cloud Tasks works

Cloud Tasks is a managed task queue. You create a task (an HTTP request aimed at a specific URL) and Cloud Tasks delivers it, retries on failure, and controls the delivery rate. Each task has exactly one consumer. There is no fan-out.

Key concepts:

• Explicit HTTP target. Every task specifies the exact URL it will hit. The task creator knows and controls the destination.
• One task, one handler. Unlike Pub/Sub, a task is not broadcast. It goes to one endpoint, once (barring retries).
• Queue controls. Each queue has configurable dispatch rate (up to 500 dispatches per second), max concurrent dispatches (default 1,000), and burst size. These settings protect downstream services from being overwhelmed.
• Retries. When a task fails (non-2xx response), Cloud Tasks retries with exponential backoff. You configure max retry attempts, min and max backoff intervals per queue.
• Scheduling. You can schedule a task up to 30 days in the future. Cloud Tasks holds the task and dispatches it at the specified time.
• Rate limiting. The queue’s maxDispatchesPerSecond setting caps how fast tasks are sent to the target. This is essential for protecting rate-limited APIs or preventing cost spikes on autoscaling services.
• Task ID deduplication. If you assign a name to a task, Cloud Tasks rejects duplicate creation requests with the same name. After a task completes or is deleted, the name stays reserved for up to 24 hours. This prevents double-enqueuing.

# Create a Cloud Task targeting a Cloud Run service
from google.cloud import tasks_v2
import json
import time

client = tasks_v2.CloudTasksClient()
parent = client.queue_path("my-project", "us-central1", "my-queue")

task = {
    "http_request": {
        "http_method": tasks_v2.HttpMethod.POST,
        "url": "https://my-service-abc123-uc.a.run.app/process-order",
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"order_id": "ord_001"}).encode(),
    },
    "schedule_time": {  # Optional: deliver 1 hour from now
        "seconds": int(time.time()) + 3600
    }
}
response = client.create_task(request={"parent": parent, "task": task})

Side-by-side comparison

When to use Pub/Sub

• Multiple services react to the same event. An order is placed and the inventory service, email service, and analytics service each need to process it independently. Each service has its own subscription.
• Event-driven architectures. Services publish events without knowing which other services consume them. New consumers are added by creating subscriptions, not by modifying publishers. See event-driven architectures in GCP.
• Data pipelines and streaming. Clickstream events, log entries, or IoT data stream into Pub/Sub and feed into Dataflow or BigQuery for processing. See designing data pipelines.
• Analytics and event streaming. High-volume event data that needs to flow to multiple destinations (dashboards, storage, ML pipelines) simultaneously.
• Loose coupling between teams. Team A publishes order events. Team B subscribes to build reports. Neither team coordinates deployments or knows each other’s implementation details.

When to use Cloud Tasks

• Background jobs off a web request. A user submits a form and you enqueue a task to process the upload, generate a PDF, or resize an image. The response returns immediately while the work happens in the background.
• Webhook and API calls to one endpoint. You need to call an external API reliably, with retries on failure and a cap on request rate.
• Delayed processing. Send a welcome email 10 minutes after signup. Charge a payment 24 hours after an order ships. Cloud Tasks holds the task and delivers it at the scheduled time.
• Rate-limited downstream systems. An external email provider allows 100 requests per second. Set maxDispatchesPerSecond on the queue to 100 and Cloud Tasks enforces the limit for you.
• Explicit retry control. You need specific retry behavior (max 5 attempts, 30 seconds between retries, give up after 1 hour) rather than Pub/Sub’s subscription-level retry policy.
• Dedupe-sensitive jobs. Assign a task name like charge-order-12345 and Cloud Tasks rejects duplicate creation attempts. Combined with idempotent handlers, this prevents double-processing.

When to use both together

Pub/Sub and Cloud Tasks are complementary. In many real architectures, Pub/Sub serves as the event bus and Cloud Tasks handles controlled downstream execution.

E-commerce order flow

1. The order service publishes an order.created event to a Pub/Sub topic.
2. The inventory service subscribes and deducts stock immediately.
3. The analytics service subscribes and records the sale.
4. The notifications service subscribes and, instead of sending emails directly, enqueues Cloud Tasks: one to send a confirmation email now (rate-limited to protect the email provider) and another to send a shipping reminder 24 hours later.

Pub/Sub handles the fan-out. Cloud Tasks handles the pacing and scheduling.

User onboarding

1. A user.signed_up event hits a Pub/Sub topic.
2. Multiple subscribers react: create a default project, provision storage, send a Slack notification to the sales team.
3. The email service subscribes and enqueues a Cloud Tasks sequence: welcome email immediately, onboarding guide in 2 hours, check-in email in 3 days, each with retry protection.

Payment and webhook processing

1. A payment gateway sends a webhook to your Cloud Run service.
2. Your service publishes a payment.received event to Pub/Sub so the order service, accounting service, and fraud detection service all get it.
3. The accounting service creates a Cloud Task to call a third-party invoicing API with rate limiting (the API allows 50 requests per second) and automatic retries.

This pattern (Pub/Sub for broadcast, Cloud Tasks for controlled single-target delivery) appears in most production systems that use both services. You can learn more in the reference architecture for modern web applications.

Cloud Tasks vs Cloud Scheduler

Scheduling is a big part of why people compare Pub/Sub and Cloud Tasks, but Cloud Scheduler is a third service that matters here.

• Cloud Tasks schedules a one-off task for a specific future time. “Send this email at 3 PM tomorrow.” The task runs once and is done.
• Cloud Scheduler runs jobs on a recurring cron schedule. “Run this cleanup job every night at midnight.” It triggers an HTTP endpoint, a Pub/Sub topic, or a Cloud Tasks queue on a repeating cadence.

Use Cloud Tasks when each job has a unique delivery time determined at creation (like a delayed notification). Use Cloud Scheduler when you need a fixed recurring schedule (like a daily report or hourly health check).

They work well together: Cloud Scheduler triggers a Cloud Run service every hour, and that service enqueues individual Cloud Tasks for each item that needs processing, with rate limiting and retries.