How does Google Cloud Pub/Sub deal with multiple App Engine instances

Question

Reading this page, https://cloud.google.com/appengine/docs/flexible/nodejs/writing-and-responding-to-pub-sub-messages, I see that pub/sub sends a message to a url you provide when there is a new message.

The reason I wanted to use pub/sub was to connect my App Engine instances together (if App Engine scales to multiple servers, I want the servers to know some of the same information). With the use of Google Cloud Pub/Sub, will all of my App Engine instances get the message, or will only one instance get the message and is there a way to make sure all of the instances get the same message?

I also checked into Pull, https://cloud.google.com/pubsub/docs/pull, and it sounds like it would work, but I don't understand how the messages are pushed without using a URL endpoint.

Answer 1

I am looking for the same thing. My usecase is this:

I have X instances of App Engine NodeJS backend. I use Redis Cloud Memorystore as caching layer. To minimize Redis use, and add performance, each backend instance also has it's own interval caching.

Rules are like this:

• first check local cache
• if found, use that.
• if not found, look in Redis cache
• update local cache with data from Redis

The local cache times out much quicker than the Redis cache, but I would still like to be able to send a "clear cache" message to all instances.

The entire thing works extremely well, but I'd like to be able to update the local caches by sending a pub/sub message which in turn would be received by all backend instances, clearing the local cache.

Yes, I could just opt not to use local caching and just Redis, but that would mean network traffic for every Redis lookup, slower responses, and more Redis resource use.

Answer 2

PubSub has two mechanisms to deliver a message:

• Push Subscriber. PubSub delivers automatically to an endpoint a message as soon as it arrives, as explained in the documentation you already checked.

• Pull Subscriber. PubSub delivers messages to a Subscriber after a pull request was explicitly performed. You can even have more than one Subscriber pulling the messages. Pulling means a client application connects to a specific subscription and requests for messages.

Both approaches can work for your chat use case, let me address it with the following approach:

1. Not acknowledge the messages.

The scope of PubSub is deliver the messages at least once. This means that as soon as an AppEngine instance reads the message and acknowledge it, such message will be removed from PubSub. Your instances can read the messages and don't ack it, in this way PubSub can retry the delivery (the messages will remain in PubSub for a default retention period of 7 days.

At certain point all the instances will have to read the same message; but you would need to implement a mechanism to identify the messages that were already read to prevent duplicates, this could be not the best solution.

2. Integrate a Publisher application, and every new chat message can be Published to Pubsub.

You would need to have a Publisher on each server your chat application depends on. All your servers (instances) would have a client that publish a message as soon as it arrives. Once received, the goal of pubsub is to deliver each message at least once; so, you would need to have an different application called Subscriber (Push or Pull) that read these messages and its responsibility is to send each message to all of your servers (please note that even when they can be the same instances, another process have to have the role of Subscriber).

Once the Subscriber sends the message to all the servers, the message can be acked and removed from PubSub. As you can have several subscribers you still would need to deal with duplicates to prevent your clients receive twice the same message