I am not sure what's the best approach, I have 10K users and each subscribes to 5 topics for a total of 50K topics, or I can change it so that each user subscribe to one topic for a total of 10K topics and use a payloadType attribute to differentiate the type of message. Basically, 10K topics with alot of message flow vs 50K topics with small message flow. Which is more salable and overall a better approach? Thanks
Mobile apps are updating their location to server and server responds with content.
Is it possible to use MQTT (Apache Artemis) for sending real time location updates from mobile application to server.
In this case is it required my server application (PHP) to subscribe for a topic?
Server has to handle all location updates through a single subscribed channel. This may slow down the server right?
Flow is like - Android clients sends user's location periodically (E.g. 30Sec) to server and the PHP server returns nearest users and app displays them on the map.
Here is the architecture I was planned using MQTT Each mobile app users id will be considered as a topic so that we can send response to each user. PHP server will considered as a topic e.g. "LOCATION_TRACKER". All mobile apps publishes location to Server topic "LOCATION_TRACKER". Server prepares the list and publish response to individual user's by using their id as topics.
In this archetecture the PHP server suscribes for topic "LOCATION_TRACKER" and in fact all mobile apps are publishing to a single topic. Consider there are millions of users how to scale the PHP server or is there any other way of doing this?
The application will target at least 10 Million users. Should support half of concurrent users.