My use case is that I have a real-time broadcast app where users get feed items based on a geolocation, i.e. a user will receive posts that were broadcasted from within a user-defined radius where (s)he currently resides.
As a backend implementation I want to use cqrs. The procedure is as follows:
- Broadcasters upload posts that are tagged with a geopoint (from where the message is sent).
- The producer places these posts on a Kafka queue on the topic "posts"
- The read-side (consumer) reads the incoming posts and stores it in a database that supports geo indices.
Users will receive updates when new posts within the user-defined radius were broadcasted by other (posting) users. It is not really required to have these broadcasted posts themselves pushed to the clients; a label with a number indicating how many new posts were broadcasted would be sufficient. The user can click / tap the number in the UI, and the new posts would be fetched with a regular http call.
In order to broadcast posts (or the number of new posts) through web sockets, I would need to evaluate for every connected user whether (s)he has a geo-radius defined that contains the current location (geo-point) in which new posts have been broadcasted. In big cities, this could theoretically be a very large number of users.
Frankly, I feel very uncomfortable with the solution of using web sockets for this use case, both in terms of performance as scalability.
When scaling out to other cities, this seems unmanageable altogether without an advanced architecture that somehow partitions posts per geo area (which I want to avoid, at least initially).
Could you give me some insight on what would be an advisable architecture to achieve the expected result?
Would you consider this a bad use case for web sockets and as such, what could be a viable / scalable alternative?
Many thanks for advice. I didn't expect this simple app concept to be as complex as it turns out to be.