[SOLVED] GCP pub sub ordering with concurrency in the subscriber

GCP pub sub ordering with concurrency in the subscriber

We have a scenario where we want to have ordered message delivery using GCP pub sub.

I had a question regarding the behavior in case we use multiple threads/concurrency (parallelPullCount) in the subscriber.

If we use parallelPullCount, does it mean that two messages with same ordering key can be delivered to the subscriber at the same time?
Or ordered messages are delivered one at a time (deliver second message only when the first one has been acknowledged) even if parallelPullCount is enabled?

Also what is the behavior in case of errors or nack?

Solution

Setting parallelPullCount does not have any impact on ordered delivery. It only controls the number of streams open to the server. Opening more streams will not make it any more likely that two messages with the same ordering key are delivered to the subscriber at once. Pub/Sub has at-least-once delivery semantics and so redeliveries can result in messages for the same key getting delivered to multiple subscribers, but they would be redeliveries, not initial deliveries of messages. As stated in the documentation:

Message redelivery: Pub/Sub delivers each message at least once, so the Pub/Sub service might redeliver messages. Redeliveries of a message trigger redelivery of all subsequent messages for that key, even acknowledged ones. Assume that a subscriber client receives messages 1, 2, and 3 for a specific ordering key. If message 2 is redelivered (because the acknowledgement deadline expired or the best-effort acknowledgement did not persist in Pub/Sub), then message 3 is also redelivered. If both message ordering and a dead-letter topic are enabled on a subscription, this behavior might not be true, as Pub/Sub forwards messages to dead-letter topics on a best-effort basis.

Pub/Sub does not guarantee that subsequent messages will only be delivered when earlier messages are acknowledged. What it guarantees is that the user callback in your subscriber client will be called for messages in the order in which the messages were published and that the callback will run to completion on a message before being called for as subsequent message. If you acknowledge messages synchronously within the callback, this essentially amounts to subsequent messages not getting delivered until previous ones are acknowledged, but if you ack asynchronously, the callback for subsequent messages will not wait for the acknowledgement of earlier messages.