Google Cloud Pub/Sub

Use it when

• You are on Google Cloud and want messaging with zero capacity management; throughput is a bill, not a setting.
• Consumers are serverless or intermittent; push subscriptions POST to webhooks, so nothing needs to run continuously.
• The stream should land in BigQuery, Bigtable, or Cloud Storage without consumer code; direct subscriptions write there natively.
• You need per-message parallelism at scale more than partition semantics, with exactly-once delivery configurable where it matters.

Think twice when

• Strict per-key ordering is central to the design; Pub/Sub is a messaging service, not a partitioned log, and its ordering contract differs from Kafka's.
• Long, repeated replay of history is routine; retention tops out at 31 days and seek-based replay is not the primary access pattern.
• Portability matters; it is Google's API, evaluated and used almost entirely inside Google Cloud.

How it runs

Fully managed and serverless over gRPC and REST, with automatic scaling and a global namespace (storage stays regional across three zones). Pull and push subscriptions, dead-letter topics, retry policies, and per-topic Single Message Transforms with JavaScript UDFs. Billing is per TiB of throughput plus storage and egress.