GCP PCA: Pub/Sub delivery, ordering, replay — seek and snapshots

How many times can it arrive, in what order, and can you get it back after an ack.

<!-- hal:authoritative:yaml -->

Three questions decide a Pub/Sub design: how many times can a message arrive, in what order, and can you get it back after someone acked it.

§I. Frame

Counter 14 mod 4 returns seat 2: GCP PCA, fifth visit. The first four covered the hierarchy, MIGs behind a load balancer, BigQuery pruning and Cloud Storage retention. None covered messaging.

The Bootcamp cheatsheet files Pub/Sub under Data & Analytics as "Message queue / event streaming," with SNS + SQS or Kinesis as the AWS equivalent. PCA-Notes adds one routing rule: if you only need to stream device data, send it to Pub/Sub directly. The CDL study guide names the common pipeline, Dataflow between Pub/Sub and BigQuery.

A PCA stem rarely asks "which service." It asks which subscription settings meet a stated guarantee. Today's Ops lesson reads those settings; this lesson grades the choice.

§II. The Delivery Ledger

The Delivery Ledger (named technique). For any stem, write three lines before reading the options: arrivals (at least once, or exactly once), order (none, or per key), recovery (none, snapshot, or seek to time).

Arrivals. Kleppmann gives the base mechanism: a broker waits for an acknowledgement, and if none arrives, "it delivers the message again" (DDIA ch11, printed p.431). In Pub/Sub the wait is the ack deadline: default 10 seconds, range 10 to 600. A nack or an expired deadline triggers redelivery.

Exactly-once delivery is a subscription setting (--enable-exactly-once-delivery) with firm limits from the vendor page:

1. Only pull subscriptions, including StreamingPull. Push and export subscriptions do not support it.
2. The guarantee holds within one cloud region. Subscribers spread across regions can still see duplicates.
3. It keys on the Pub/Sub message ID. A publisher that retries and publishes twice creates two message IDs, and the subscription receives both.
4. Without an explicit ack deadline at creation, these subscriptions default to 60 seconds, and publish-to-subscribe latency is "significantly higher."

So "exactly-once" in a stem still needs an idempotent consumer whenever the publisher can retry.

Order. Ordering is opt-in on the subscription, and the publisher must set an ordering key. Messages "sent in the same region, with the same ordering key" arrive in publish order. Acks for later messages wait on earlier ones, and with exactly-once on as well, throughput is limited to "an order of thousands of messages per second."

Recovery. This is where Pub/Sub departs from a plain queue. DDIA contrasts AMQP/JMS brokers, where acknowledging "is a destructive operation," with log-based brokers, where a consumer can re-read from an old offset (printed p.436). Pub/Sub sits between them, and the setting decides which side you are on.

§III. Seek and snapshots

Two replay tools, with different preconditions:

gcloud pubsub snapshots create pre-deploy-0928 --subscription=payments-worker
gcloud pubsub subscriptions seek payments-worker --snapshot=pre-deploy-0928
gcloud pubsub subscriptions seek payments-worker --time=2026-09-28T09:00:00Z

Facts from the seek page that decide exam answers:

1. A snapshot cannot be created if it would expire in less than one hour. An old backlog shortens every snapshot's life.
2. Seeking to a time in the future purges the backlog in bulk.
3. Seek is eventually consistent: "it might take as long as a minute" to take full effect.
4. On a subscription with a dead-letter topic, a seek resets delivery attempts to 0.
5. A snapshot can be applied to any subscription on the same topic, including a new one.

None of this helps a subscription that no longer exists. The Ops lesson's deletion clock applies here: an expired subscription takes its backlog and its seek history with it.

§IV. Worked scenario

A payments service deploys subscriber code every Tuesday. Requirements: recover from a bad deploy that acked messages it should not have, for up to three days; process each account's events in order; never charge twice.

1. Recovery: set retain_acked_messages with retention of at least three days, so a seek to a timestamp before the deploy replays acked messages. Add a snapshot at deploy time as the fast path; it needs no retention setting, but its life depends on the backlog age.
2. Order: enable message ordering and publish with the account ID as the ordering key.
3. No double charge: exactly-once on a pull subscription, subscribers in one region, and an idempotent charge keyed on a business ID, because publish retries create new message IDs.
4. Reject push delivery here. It rules out exactly-once.

§V. Drills

1. A stem needs exactly-once and a push endpoint on Cloud Run. What do you change? Switch to a pull subscriber; push does not support exactly-once.
2. An operator runs a seek to yesterday on a default subscription and gets no acked messages back. Why? *Neither retain_acked_messages nor topic retention was set.*
3. The oldest unacked message is 6 days 23.5 hours old. Can you snapshot? No. The snapshot would expire in 30 minutes, under the one-hour floor.
4. Ordering is enabled, yet messages arrive out of order. First check? Whether the publisher sets an ordering key and publishes in one region.
5. A dead-lettered message is replayed by seek. What is its delivery-attempt count? 0.

§VI. Traps

1. Picking exactly-once and forgetting publisher retries.
2. Assuming snapshots last seven days no matter what.
3. Choosing seek to a timestamp without retention set on the subscription or topic.
4. Enabling ordering on the subscription and never setting a key on the publisher.
5. Recommending a fresh subscription to "replay" history. Without topic retention or a snapshot to seek to, it only sees what is published after it exists.

§VII. Close instruction

Write the Delivery Ledger for the payments scenario in three lines, then change one requirement (drop the three-day recovery) and state which setting you remove and what it saves.

Related

• Ops: Pub/Sub subscription expiry census (same trio)
• Dev: mpsc fan-out, one thread per subscription (same trio)
• Prior PCA: Cloud Storage lifecycle and retention
• the study notes/cloud-certification-exam-prep/cheatsheets/gcp-ace-pca.md — Data & Analytics, Pub/Sub row