Expected latency with GCP Pub/sub synchronous pull subscription

Question

My application is going to receive certain events from GCP Pub/sub and application is supposed to process these events using a cron job (mostly hourly). So, I am planning to use a synchronous pull subscription so that I can retrieve fixed no of messages during each job run. However, I came across some articles on web claiming that latency can be very high for a synchronous pull. Can someone who has used it before please post how much average latency can be for a synchronous pull?

Answer 1

It's difficult to produce an actual "average latency" number because the factors in each use case can impact it. End-to-end latency for unary pull can be higher than streaming pull by virtue of the fact that Pub/Sub cannot deliver messages until there is an outstanding pull request to which to send messages. With streaming pull, a stream is available and so messages can be sent to it as soon as they are published.

However, it doesn't sound like end-to-end latency is really a concern for you if you are processing messages in batch every hour. You will have to keep in mind that Pub/Sub may not return all of the available messages in a pull response and that an empty pull response is not an indication that there are no messages available. This is because Pub/Sub does try to balance more full requests against end-to-end latency. Therefore, you may have to make several requests in order to get all of the messages you want. If getting the messages quickly when your cron job does come up is important and you still want to use unary pull, then send many pull requests simultaneously.