Evaluate http reqres vs websockets for geolocation based broadcasts

Question

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.

Answer 1

architecture that somehow partitions posts per geo area (which I want to avoid,

Unfortunately that is exactly what you should be doing.

First of all, drop kafka. Its not a message queue.

Secondly, when a user posts you want to tag that post with one or more area aggregate keys; say post code or grid square or city rather (or as well as) the geo-location.

Now you can have a queue per location tag that you publish the post to and other users can subscribe to the location tag nearest them.

If the area is too big, the client can trim out the extra posts

If the client is near the edge of an area they can request more than one area. (or you can use overlapping areas)

In terms of websockets vs polling. Yes websockets dont scale well if you leave them open. But neither does the client spamming refresh. You can probably use a combination of websockets, mobile push messaging and switching to polling if the client appears inactive. But unfortunately TCP/IP isn't really built for broadcast media.