Google Cloud Pub/Sub

n/a (managed service, no version)

matureCost: lowTeam: juniorLatency: tens of msDurability: persistent

Summary

Fully managed, serverless publish-subscribe messaging service offering global topic fan-out to multiple independent subscriptions, at-least-once delivery by default with an optional exactly-once delivery mode, and automatic scaling with no partition or shard count to provision.

Primary Use Case

Fan-out event distribution where multiple independent consumer systems each need their own durable, independently-progressing view of the same event stream, on GCP, without operating a broker or provisioning throughput capacity ahead of demand.

Workload Fit

async decouplinglow medium volume eventslog aggregation

Strengths

Best for

·Fan-out to multiple independent consumer systems on GCP without provisioning a broker
·Event distribution where each downstream system needs its own durable, independently-progressing subscription
·Serverless architectures (Cloud Run, Cloud Functions) needing push-delivery messaging with zero broker infrastructure

Excels when

·Multiple independent teams or systems each need their own full copy of the same event stream
·The team wants zero broker operations and automatic throughput scaling with no partition planning
·GCP-native push delivery to serverless compute is preferred over pull-based consumer polling

Architectural advantages

·Subscription-level fan-out gives each consumer an independent cursor with no shared partition assignment to coordinate
·Zero operational burden: no broker to patch, scale, or fail over, Google owns all of it
·Push delivery to HTTPS endpoints removes the need for a long-running consumer process for simple fan-out

When to Avoid

Avoid when

·Cross-cloud or on-premises portability is required: Pub/Sub is GCP-only with no self-hosted or other-cloud equivalent
·Strict, global message ordering across an entire topic is required: ordering keys only guarantee order within a key
·Fine-grained partition-level control (custom partitioning schemes, manual rebalancing) is a hard requirement

Common misuses

·Assuming a single subscription behaves like a Kafka consumer group with automatic load balancing across independent teams: each team needing independent progress must create its own subscription
·Not enabling exactly-once delivery mode when the consumer is not idempotent: default delivery is at-least-once and duplicates are expected
·Treating retention as unlimited: unacknowledged messages still expire at the configured retention limit

Consistency & Transactions

Consistency modeleventual

ACID compliantNo

Supports transactionsNo

Scaling

Characteristics

horizontal readhorizontal writeserverless

Operational burdenlow

Typical read latency15 ms

Typical write latency15 ms

Read scalability

Each subscription scales independently; adding subscribers within a subscription's pull pool distributes that subscription's messages, and adding entirely new subscriptions to the same topic does not affect existing subscriptions' throughput or ordering. There is no partition count to provision for parallelism.

Write scalability

Publish throughput scales automatically with no pre-provisioned shard or partition count; Google manages topic sharding transparently behind the API. Ordering keys reduce effective write parallelism for messages sharing a key, the same tradeoff as any per-key ordering scheme.

Failure Behavior

Known failure modes

·Ack-deadline expiry redelivers a message even without consumer failure, if processing exceeds the deadline, the same visibility-timeout-style duplicate risk as SQS
·Ordering keys serialize all messages sharing a key behind a single subscriber; a hot key throttles that key's throughput independent of overall topic capacity
·Dead-lettering (per-subscription, configurable delivery attempt threshold) is opt-in per subscription: a subscription without it configured retries indefinitely against its own ack-deadline expiry
·Exactly-once delivery mode has a bounded deduplication window; redelivery outside that window can still duplicate-process

Bottlenecks

·Ordering-key hot-keying serializes messages sharing a key behind one subscriber, the same constraint as a hot Kafka partition key
·Per-subscription dead-lettering and retention must each be configured individually; a fan-out to many subscriptions multiplies configuration surface

Degradation patterns

·Ack-deadline expiry under sustained subscriber slowness redelivers messages rather than visibly backlogging, similar to SQS visibility-timeout duplication
·A slow or stalled subscription accumulates unacknowledged messages up to its retention limit, independent of how fast other subscriptions on the same topic are progressing

Recovery considerations

·Each subscription's redelivery and dead-lettering recovers independently; a stalled subscription does not block other subscriptions on the same topic
·Seek-to-timestamp (subscription replay within the retention window) provides limited catch-up recovery, narrower than Kafka's full offset-based replay

Operational Pitfalls

·Not configuring per-subscription dead-lettering: unlike SQS's queue-level redrive policy, each Pub/Sub subscription needs its own dead-letter configuration
·Assuming default at-least-once delivery is exactly-once: duplicate processing requires idempotent consumers unless the explicit exactly-once mode is enabled and its window respected
·Fanning out to many subscriptions without accounting for each subscription's independent retention and redelivery cost: cost and backlog scale per-subscription, not per-topic

Architecture Guidance

Common topology roles

event busasync busfan out dispatcher

Migration notes

·From Kafka to Pub/Sub: consumer groups map to subscriptions, but partition-level manual assignment has no equivalent, Pub/Sub manages sharding transparently
·From SQS to Pub/Sub: SNS-plus-SQS fan-out (topic plus multiple queues) maps directly to a single Pub/Sub topic with multiple subscriptions, removing the need for a separate fan-out service

Advisor Guidance

Info

When: scenario needs one event stream fanned out to multiple independent consumer systems

Pub/Sub subscriptions give each consumer system an independent durable cursor with no shared partition coordination; create one subscription per independent consumer

Warning

When: scenario assumes exactly-once delivery without configuring the explicit exactly-once mode

Default Pub/Sub delivery is at-least-once: consumers must be idempotent unless exactly-once delivery mode is explicitly enabled and its deduplication window respected

Comparison Factors

operational complexity

Lowest of any broker profile: no capacity planning, patching, or HA configuration, Google owns all of it

low

fan out model

Subscription-level: each independent consumer gets its own full copy with no shared partition assignment

high

message replay

Limited: seek-to-timestamp within the retention window, narrower than Kafka's full offset-based replay

medium

portability

GCP-only, no self-hosted or other-cloud equivalent

low

Managed Cloud Options

Google Cloud Pub/Sub (fully managed, no self-hosted option exists)

Enables Patterns

publisher subscriberdead letter queue

Basis

Fully managed GCP service with stable, well-documented behavior; subscription fan-out and ack-deadline semantics are precisely specified in Google Cloud documentation

Sources & Claims

Each Pub/Sub subscription is an independent, durable cursor over a topic: creating a new subscription does not consume or redistribute messages an existing subscription already sees, and each subscription receives its own full copy of every message published after its creation

pending

official documentation · Google Cloud Pub/Sub documentation, Subscriber overview

messaging-knowledge-completion batch, added alongside SQS and Pulsar profiles

Pub/Sub delivery is at-least-once by default; an optional exactly-once delivery mode can be enabled per subscription, which deduplicates redelivery within a bounded window rather than guaranteeing exactly-once processing unconditionally

pending

official documentation · Google Cloud Pub/Sub documentation, Exactly-once delivery guide

messaging-knowledge-completion batch