Pub/Sub
Pub/Sub is Google Cloud's messaging service — global, anycast, and at-least-once by default. It is the foundation of decoupling on GCP: when component A needs to tell component B something but should not wait for B, A publishes a message to a topic and B subscribes. The decoupling is total. Either side can scale, restart, or be replaced without the other knowing.
Pub/Sub is the right hammer for many problems and the wrong hammer for a few specific ones. The most common architectural error is using it as a generic queue when the workload actually needs Cloud Tasks (rate-limited HTTP) or Workflows (orchestration). Knowing where Pub/Sub fits, and where it does not, matters more than knowing its API.
Topics and Subscriptions
A topic is a named channel that publishers send messages to. A subscription attaches to a topic and delivers each message to one of its consumers. Multiple subscriptions on one topic are independent — each receives every message and acks separately. This is what makes fan-out work: one publish, many consumers, no extra cost beyond per-subscription billing.
Unacknowledged messages are retained for a configurable window — 7 days by default, up to a maximum of 31 days. After ack, they are gone. For replay or historical analysis, route a copy to Cloud Storage or BigQuery; do not treat Pub/Sub as durable long-term storage.
Push vs Pull Delivery
Pull subscriptions let consumers fetch messages on their own schedule. Best for high throughput and when consumers can control concurrency precisely — the Pub/Sub client library handles flow control and parallelism. The default for batch processing, stream workers, and any consumer running on a long-lived VM or container.
Push subscriptions deliver messages by calling an HTTP endpoint you specify. Best for serverless backends (Cloud Run, Cloud Functions) where you do not want an always-running pull worker. Push always uses HTTPS; private destinations require OIDC tokens. Failed deliveries get retried with backoff according to the subscription's retry policy.
Delivery Guarantees
At-least-once is the default. Pub/Sub guarantees every published message will be delivered at least once to each subscription — duplicates are possible and your handler must be idempotent. Exactly-once delivery is opt-in per subscription. It deduplicates within a tracking window so that successful acks count as the only delivery. The trade-off is throughput and latency overhead. Enable it where duplicate handling is genuinely impossible (financial postings, primary-key inserts), keep at-least-once for the rest.
Ordering Keys
By default, Pub/Sub does not guarantee order — parallel delivery is the whole point. Ordering keys ask for in-order delivery within a key: messages with the same key arrive in publish order; messages with different keys remain parallel. The cost is real: per-key serialization caps throughput on that key to a single consumer at a time. Use ordering keys only when order genuinely matters for correctness (per-user event stream, per-account transactions), never for convenience.
Dead Letter Topics and Retry
A dead letter topic (DLT) receives messages that have exceeded the configured maximum delivery attempts. Without a DLT, a permanently failing message ("poison message") cycles forever, consuming budget and clogging the subscription. Configure a DLT on every production subscription and set a reasonable max_delivery_attempts (typically 5–10). Then alert on DLT depth — every message there is an unprocessed error worth investigating.
Schemas and Validation
Pub/Sub topics can be bound to a schema (Avro or Protocol Buffers) that validates publishes at runtime. Wrong-shape messages are rejected at the topic boundary instead of poisoning every consumer downstream. For any topic with a stable contract between teams, attach a schema — it transforms "the publisher made a typo and broke production" from an outage into a 4xx on the publisher.
Pub/Sub vs Pub/Sub Lite
Pub/Sub Lite was a separate, cheaper, partitioned, single-region product often confused with Pub/Sub itself. Google has retired it: closed to new customers since September 2024 and shut down on June 30, 2026. Do not design new systems around it — use regular Pub/Sub, or Managed Service for Apache Kafka when partitioned, capacity-reserved throughput is genuinely required. The comparison below remains useful only for understanding legacy systems still referencing Lite.
Pub/Sub — global, auto-scaling, fully managed. The default for almost every workload. Higher per-message cost but no capacity planning.
Pub/Sub Lite — regional, partitioned, capacity-reserved, and roughly 10x cheaper per byte at scale, but you managed partitions and capacity yourself. Retired (closed to new customers Sept 2024, shut down June 30, 2026); for that workload shape, reach for Managed Service for Apache Kafka instead.
- No dead letter topic on a production subscription — one poison message cycles forever, consuming budget and blocking debugging.
- Acking before the work is durably persisted. The handler crashed mid-write, Pub/Sub will not redeliver, the message is lost.
- Push subscriptions to private endpoints without OIDC token configuration — every delivery returns 401 and stacks up in retries.
- Ordering keys applied broadly when only a few flows need order — throughput collapses on hot keys because each key serializes.
- Assuming exactly-once is the default. It is opt-in per subscription; without enabling it, plan for duplicates.
- Slow subscribers without flow control. The client library buffers grow until publishers see backpressure or your consumer falls hours behind.
- Using Pub/Sub when the real need is rate-limited HTTP callbacks with retry — that is Cloud Tasks territory, not Pub/Sub fan-out.
- Dead letter topic on every production subscription, with alerting on DLT depth.
- Schemas (Avro or Protobuf) on topics with a stable contract — push wrong-shape messages back at the publisher boundary.
- Ack only after the work is durably persisted. Handlers must be idempotent.
- Flow control sized to actual consumer throughput, not to maximum theoretical.
- OIDC tokens for push subscriptions to private destinations; never expose a Pub/Sub endpoint to the public internet without auth.
- Ordering keys only on flows where order is a correctness requirement, not a convenience.
- Route a copy of important topics to BigQuery or Cloud Storage for replay and audit — Pub/Sub itself is not long-term storage.
Knowledge Check
What is the default delivery guarantee in Pub/Sub?
- Exactly-once — every published message is delivered exactly one time per subscription, with the service deduplicating any retries on your behalf so handlers never see a repeat
- At-least-once — every published message is delivered at least one time per subscription, with possible duplicates; handlers must be idempotent
- At-most-once — messages may be silently dropped under load
- Best-effort — no guarantees beyond eventual delivery within the retention window
What does a dead letter topic do?
- Stores a permanent copy of every message that was ever published on the topic so the full history can be replayed to a new subscriber at any later time
- Receives messages that have exceeded the subscription's max delivery attempts, so poison messages stop cycling forever and can be inspected
- Aggregates ack rates across all subscriptions of a topic for monitoring
- Triggers cross-region replication when the primary region fails
What is the principal cost of using ordering keys in Pub/Sub?
- A per-message fee surcharge applied to every keyed publish
- Per-key serialization — messages with the same key are processed in publish order by a single consumer at a time, capping throughput on hot keys
- Ordering keys disable dead letter topics on the subscription, so any message that exhausts its delivery attempts must be caught and handled in-band by the consumer instead
- Schemas cannot be attached to topics that use ordering keys
What is the current status of Pub/Sub Lite?
- It has been retired (closed to new customers in 2024, shut down June 30, 2026); new designs should use regular Pub/Sub or Managed Service for Apache Kafka
- It is the modern replacement for Pub/Sub and supports the same features at lower cost
- It is the right choice for any global, exactly-once workload with minimal operational overhead, since it auto-scales capacity across regions with no partitions to provision
- It is the only Pub/Sub option that supports schema validation
A push subscription delivers to a Cloud Run service on a private URL and every delivery returns 401. What is the most common cause?
- The subscription's ack deadline is set too low for the handler to respond in time
- The push subscription is not configured with an OIDC service account, so requests reach the private endpoint without authentication and are rejected
- Pub/Sub push subscriptions cannot deliver to private Cloud Run services under any configuration, so the service must be redeployed with public ingress before push works at all
- Exactly-once is enabled and the deduplication tracking window has not yet expired
You got correct