Motivation

We recognized that Google Pub/Sub does not implement any logic for delayed delivery except by NACK’ing messages, and this approach has the following disadvantages & pitfalls:

  • Because of performance reasons, Google Pub/Sub delivers messages (transparently) in batches. If one batch message is NACK’d, the whole batch is redelivered, which can lead to a high number of duplicates.

  • Although Pub/Sub subscriptions offer the possibility to specify a retry policy for NACK messages (immediate or exponential), this does not fit most of the use cases we have in ME because:

    • The maximum delay is limited to 600s (10 minutes) and

    • Additionally, it is impossible to specify a delay in case of NACK’ing a message programmatically.

The concept for the delayer service was approved during the ADB meeting.