Why Does Google Cloud Pub/Sub Process Messages Concurrently for the Same OrderingKey Before Acknowledgment?

Below is an explanation of why you’re seeing concurrent delivery and what you can do (using only configuration changes, not local queue logic) to more closely enforce sequential processing.

1. Why Are Messages Delivered in Parallel?

Even though you enable message ordering on the subscription and use the same ordering key on publishing, Google Cloud Pub/Sub guarantees ordering only when the publisher sends messages and if the subscriber processes them synchronously at one “slot.” In streaming pull, the subscriber client library is optimized for throughput and by default will issue message requests concurrently. This means that even if messages share an ordering key, they may be delivered in parallel across the connection. Pub/Sub does not “pause” delivery of the next message waiting for you to ack the previous one—it simply ensures that when a message delivery fails (for example, due to a processing error) the system will later re-deliver messages in order for that ordering key.

2. How to Enforce Sequential Processing

Since Pub/Sub itself does not block the delivery of the next message until ack is called on the current one, you must configure the subscriber’s flow control to restrict the number of unacknowledged messages. For example, you can limit the maximum number of messages in flight to one. This way the subscriber will fetch only one message at a time for the entire subscription (which, if you have a single ordering key, enforces sequential processing).

If you are using the Node.js client library, you can adjust the flow control settings when creating your subscription object. For example:

JAVASCRIPTCopied
const { PubSub } = require("@google-cloud/pubsub");
const pubSubClient = new PubSub();

const subscription = pubSubClient.subscription("YOUR_SUBSCRIPTION_NAME", {
  flowControl: {
    maxMessages: 1, // Ensures only one message is in-flight at any given time.
  },
});

subscription.on("message", async (message) => {
  try {
    console.log(`Message received: ${message.id}, orderingKey: ${message.attributes.orderingKey}`);
    const data = JSON.parse(message.data);

    // Simulate long processing
    await new Promise((resolve) => setTimeout(resolve, 5000));
    console.log(`Message processed: ${data.orderId}`);
  } catch (err) {
    console.error(`Error: ${err}`);
    return;
  } finally {
    console.log(`Calling message.ack() for: ${message.id}`);
    message.ack();
  }
});

By setting maxMessages: 1, the subscriber will only request one message at a time from Pub/Sub. With a single ordering key in use, this configuration enforces sequential message processing without needing to implement your own queuing logic.

Summary

1. Parallel Delivery Reason: Pub/Sub’s delivery system is optimized for throughput. It does not hold off delivery of the next message even if the previous message hasn’t been acknowledged—delivery order is managed within Pub/Sub on the publisher side and in error re-delivery—but concurrent processing on the subscriber side is expected.

2. Enforcing Sequential Processing: The subscriber’s flow control settings can be configured (in Node.js, for instance, using maxMessages: 1) to restrict parallel delivery. This ensures that a new message (even with the same ordering key) won’t be fetched until the previous message is acknowledged.

These configuration changes are the only way to approximate strict in-order processing given the current Pub/Sub behavior without adding additional logic to manage message order locally.