The short answer
Google Cloud Pub/Sub is a globally distributed, horizontally scalable messaging service. By default, Pub/Sub prioritizes throughput and low latency: messages are distributed across multiple publisher servers and subscriber workers, which means messages can be delivered out of chronological order and may be redelivered if acknowledgment deadlines expire.
In financial transactions, inventory changes, and database (CDC), message order and deduplication are mandatory.
Message ordering with Ordering Keys
To guarantee strict chronological delivery for related events:
- The publisher attaches an Ordering Key (such as
customer_idororder_id) to the message metadata payload. - Pub/Sub hashes the ordering key and routes all messages sharing that key through the same internal broker pipeline.
- Subscriber clients receive messages for that specific key in the exact order they were published.
- If a message fails acknowledgment, delivery of subsequent messages for that key pauses until the blocking message is successfully processed or reaches maximum retry limits.
Exactly-once delivery subscriptions
Standard Pub/Sub subscriptions guarantee . If a subscriber worker takes longer to process an event than the acknowledgment deadline, Pub/Sub redelivers the message to another worker, creating duplicate records in downstream databases.
Enabling Exactly-Once Delivery on a subscription eliminates duplicates:
- Pub/Sub tracks message acknowledgment IDs across Google's distributed coordinator.
- If an acknowledgment is received successfully, any pending redelivery is canceled cluster-wide.
- If a worker acknowledges a message after the deadline has expired, Pub/Sub rejects the late acknowledgment and informs the worker, preventing concurrent dual-processing.
For records that repeatedly fail due to deserialization bugs or schema mismatches, configure a Dead Letter Topic to route poison-pill messages away after five failed delivery attempts without stalling the pipeline.