It's more like 1) Application sends a message w/ ordering key "abc" (let's call it msg1) 2) Pub/Sub gets msg1. 3) Pub/Sub acknowledges that msg1 was received.

It's more like 1) Application sends a message w/ ordering key "abc" (let's call it msg1) 2) Pub/Sub gets msg1. 3) Pub/Sub acknowledges that msg1 was received. Now, you can be secure we have stored this message durably. 4) Pub/Sub sends msg1 to the subscriber ASAP if there's one available. 5) A subscriber client assigned to ordering key "abc" gets msg1. 6) The subscriber client processes msg1 and sends an ack to Pub/Sub. 7) Pub/Sub receives the ack and removes the message from storage. (It's possible to retain acked messages, but let's not talk about that for simplicity.) Another message for the same ordering key "abc" arriving at Pub/Sub any time after step 4 will be delivered to the subscriber only after msg1. To summarize, the timestamp of a successful publish response is the timestamp by which we order messages sent to the client. Pub/Sub may not send messages immediately if the subscriber is too slow to ack the message (perhaps each message takes a while to process) or if the subscriber is down or if there's too many messages in the backlog for the ordering key. In these cases, you can be assured that they're safely stored on disk and will be resent later (after some backoff period.) So, to answer your question directly, we only stall the sending of ordered messages to subscribers if there's a backlog for that ordering key or if the subscriber not fast enough.