How will a popular project handle rate-limit for topic subscriptions per project?

Question

Introduction

So from the official firebase docs. It states there that:

The frequency of new subscriptions is rate-limited per project. If you send too many subscription requests in a short period of time, FCM servers will respond with a 429 RESOURCE_EXHAUSTED ("quota exceeded") response. Retry with exponential backoff.

The topic subscription add/remove rate is limited to 3,000 QPS per project.

qps = queries per second.

Now here's the thing. It says "per project". What if an app gets very popular and thousands of users open the app at the same time then click a button that subscribes to a topic or unsubscribe?

Wouldn't hitting the rate limit 3000 queries per second highly possible?

Here's my real question

Does firebase_messaging's subscribeToTopic(..) and unsubscribeFromTopic(..) methods automatically handle retries? (referring to "Retry with exponential backoff" above)

If not, then how would a very popular app handle topic subscriptions from a massive number of users?

Because the plugin does not provide any documentation about this.

Answer 1

Coming from a different platform (Android) for your question on subscribeToTopic() retry?, but possibly both function similarly. On Android it returns a Task where in Flutter it returns Future (Task = Future for Flutter if I understood that correctly), which I presume is a hint that Google gave the responsibility for the retries to the developers.

I'm not sure what your looking for as an answer. The correct way is to implement an exponential backoff as mentioned in the docs. Depending on your use-case, different strategies can be implemented.

e.g. forced subscription -- like a general topic, that runs every app start is easy. One-off subscriptions, you might need some verifications i.e. a way to check if the user actually finished subscribing, retry if not.