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 — a message may be silently dropped under load, and the service never redelivers it to the subscription afterwards
- Best-effort — no guarantees at all beyond eventual delivery at some point inside the message retention window of the subscription
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 the ack rates across every subscription attached to a topic so that they can all be monitored from a single dashboard in Cloud Monitoring
- Triggers cross-region replication of the topic whenever the primary region fails or becomes unreachable for a time
What is the principal cost of using ordering keys in Pub/Sub?
- A per-message fee surcharge applied to every keyed publish, which makes ordered topics markedly more expensive than unordered ones at the same message volume
- Per-key serialization, where messages sharing a key go to a single consumer in publish order and throughput on a hot key is capped
- 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 any topic that uses ordering keys, so message validation has to be handled by the publisher in application code entirely
What is the current status of Pub/Sub Lite?
- It has been retired (closed to new customers in 2024 and shut down on June 30, 2026); new designs should use regular Pub/Sub or Managed Service for Apache Kafka instead
- It is the modern replacement for Pub/Sub and supports all of the same features at a noticeably lower cost per message published
- It is the right choice for any global, exactly-once workload with minimal operational overhead, since it auto-scales across regions with no partitions to provision
- It is the only Pub/Sub option that supports schema validation on the messages published to a topic, so schemas force its use
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, so the deliveries just keep being retried
- 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 delivery is enabled and the deduplication tracking window on the subscription has not yet expired for those messages
You got correct