We are facing a dillema regarding scalability for our backend service. The backend service will be registered as a public app with RC.
The scenario is that our clients can become RC clients. If they do, they will also want to integrate our sass solution Intelligent office (IO) with RingCentral. The goal of the integration is to show all the call logs in IO. In addition to that, we will download call recordings and store them in our servers for later user.
RC clients (our customers) will enter admin user details into our system, so that our backend job could run in the background and receive call notifications. We are subscribing to presence events for multiple extensions using admin user credentials for each tenant/ RC customer. As I understand, RC internally uses PubNub to deliver notifications as soon as they happen by means of HTTP long polling.
This works all fine in sandbox, where we have just 1 RC account. My question/concern would be how do we ensure that our backend services scale well when we start adding more RC accounts. I don't believe that having more than 20 subscriptions for different RC accounts would work well, as that would mean 20 HTTP Long polling loops just for the PubNub notifications.
What would be the best strategy here to divide the load, or ensure this scales well. I do hope we are not the first to do this sort of bacekend processing.