System Design: Real Time Location Based Notification System

Problem Statement
How to design a Live Location Based Notification system using Firebase Messaging with Android / iOS Apps?

Scenario

• User A creates a report
• If User B is located within a 5km radium of User A's report location, User B should get a notification (ie: all nearby users get notified)

The app can have 1000's of concurrent users, publishing reports frequently.

Notifications should be delivered as real time as possible.

The notification should be delivered to anyone with the app within a 5km radius. Using GeoFencing option, where device wakes up in a certain area is not an option, as user should always be notified when a report near them happens.

Considered Approaches

A:

• Upload user locations to server every so often and store in database
• When new report, find users within radius, and send notification to each individual device/FCM token

Cons:

• Have to constantly upload user location to server (server load, scalability, privacy)

B:

• Each client app subscribes to FCM Topic such as 'new-reports'
• When new report, server publishes 'data-only' FCM event to 'new-reports' topic
• FCM sends message to all devices, device wakes up and checks if users is within report radius
• If so, app creates notification

Pros:

• Less server processing

Cons:

• Does not work with iOS, as background data only messages are not always delivered to iOS clients
• Event sent to every user of app - regardless of if they're in that area or not

Approach B seems the lesser of 2 evils to me, however does not work with iOS due to data only messages not being delivered on iOS in background. Approach A sounds like a battery drain, and potential privacy concern if have to keep sending location to server.

Any thoughts on what a good approach would be to take here?

B isn't going to scale to thousands of users. Let's say you have N users each with R reports per hour. That means you have NR reports per hour total. You need to send that to N users, meaning N^2R messages per hour. Your load scales at the square of your number of users. You'll spend a fortune on servers and processing. Not to mention that you'll quickly hit message limits (power savings mode only allows so many messages per hour before they stop allowing high priority push notifications). While A is the better one for privacy, it does not scale. Realistically you'll have no privacy with this app anyway, anytime you send a report to the server you'd have to send the location.

If you want to obscure location a bit, break the map into zones and only report what zone you're in (the whole 5km circle thing was never going to work well anyway since its so much more efficient to just do less accurate but faster lat/lng lookups without calculating exact circles). Then you'd only have their locations going to the server in 25 square km blocks.

Here's the approach I ended up using which addresses a lot of the cons above.

1. When a new report is created, calculate the GeoHash at that latitude, longitude
2. Publish report to FCM topic, 'new-reports-< geohash value >'
3. Android/iOS Client subscribes to 'new-reports-< geohash near them>'
4. Repeat Step 3 for all geohashes that fall within the 5km radius

The main con with this approach is around accuracy - eg: 5km radius may fall into half of a GeoHash Zone, meaning you get notified even though it's outside the 5km radius. For my purposes, this tradeoff is acceptable as it does not have to be extremely accurate.

Read more on GeoHashes here.