How Does Google Pub/Sub Handle Message Recovery in a Downed Spring Boot Service?

Overview

When your Spring Boot application subscribes to a Google Cloud Pub/Sub subscription, messages published to the topic are held in the subscription until they are acknowledged by your service.

Behavior When the Service Is Down

• Message Retention:
  If your service is down and new messages are published to the topic, these messages are stored in the subscription's backlog. They are retained for a configurable period (default is 7 days). As long as the messages are still within this retention period, they remain deliverable.

• Redelivery:
  Once your service comes back up, it can receive the messages from the subscription backlog. Google Pub/Sub guarantees at-least-once delivery, so any message that wasn’t acknowledged previously will be redelivered.

Things to Consider

• Acknowledgment Deadline:
  Make sure your application's message processing logic acknowledges messages after successful processing. If processing takes longer than the current acknowledgment deadline, you may need to adjust this setting to avoid unintentional redelivery.

• Subscription Type (Push vs Pull):

  • For pull subscriptions (commonly used with Spring Boot), your application actively pulls messages when it’s up.
  • For push subscriptions, the Pub/Sub system sends the messages. If your endpoint is down, Pub/Sub will continue trying to push the message until it either succeeds or the message retention period expires.

• Handling Duplicates:
  Since Pub/Sub delivers messages at least once, be prepared to handle duplicate messages in your application logic.

Summary

Yes, if your service is down and messages are published to your Pub/Sub topic, those messages will accumulate in the subscription’s backlog. When your Spring Boot application restarts and reconnects to the subscription, it will receive the backlog messages (provided they have not expired) and process them accordingly.