Managing FCM topics for devices when changing signed in user

[Will Battel]

I'm working to integrate push notifications into my Firebase app with FCM and have a design question I'd like some insight on.

My app has several different categories of notifications, some of which are to be delivered via topics and others directly to a list of device tokens. The former for global messages such as featured content, news, etc., and the latter for user-specific notices like personal interactions by other users. My question here refers to the former.

I allow the user to specify which types of notifications they want, and save these preferences to a user document in Firestore. I think it makes much more sense for the preferences to be tied to the user account, rather than the device, and then share those preferences with all devices the user is logged into. The only thing the device should be concerned about is whether or not it is registered for said notifications. This all should be fine except for the scenario where the user logs out or switches accounts.

Users are able to log out of their account and optionally log into a different one. Only one user can be logged in at a time, but still there is some complexity regarding topic management during login and logout.

In theory, I'm thinking that when a user logs out on a device that it would be best to unsubscribe the device from the topics they had enabled so that they don't get notifications tied to the preferences of a signed-out user. If USER A wants to receive messages from "news/foo" topic, and then signs out of the device and USER B signs in and wants messages from "news/bar", then that device should be unsubscribed from "news/foo" and subscribed to "news/bar" so as to receive the messages configured by the currently-signed-in user.

Because I store the preferences in Firestore, it logically shouldn't be challenging to unsubscribe topics on logout, and resubscribe on login. However, I'm thinking that this may be a bad practice at-scale when the user could theoretically have many topics that must be updated individually.

One particular note in the docs leads me to think that this may not be a wise approach:

"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."

from https://firebase.google.com/docs/cloud-messaging/ios/topic-messaging

So it seems I should be considerate with my subscription requests, and look for alternative solutions here. So here are my questions:

1. Am I correct that mass-topic updating upon auth state change is a bad idea? If a user is subscribed to 50 topics then I have to send 50 unsubscribes when they log out on a device and 50 subscribe requests when they log in on a device. Both are not very common occurrences relatively-speaking but that seems like a problem at-scale.
2. What alternative solutions might there be? How do other apps do it? What is a good solution for scale? Am I looking at this the wrong way or not understanding certain behavior? We could theoretically over-engineer a solution on Cloud Dataflow, for example, that targets registration tokens directly and avoids FCM Topics entirely but that seems like the unnecessary nuclear option for what I would presume is a fairly common use-case.

Thanks!

[Александр Емелин]

Hello Will,

I am currently thinking about similar things. What I ended up is working on a system which manages topics itself, just using FCM tokens for sending, but the topic storage and topic broadcast logic is a task for an application. Seems that this design allows reducing overhead of topic management to some degree as attaching (or deattaching) topics to the device is a single call (instead of many individual calls). So this is close to the nuclear option 2 from your post.

Curious what solution you eventually ended up with?