How We Architect Real-Time Geofencing at Scale: PostGIS, Push Pipelines & Sub-60-Second Alerts

Every location-based alerts product — deals apps, delivery tracking, safety alerts, hyperlocal marketplaces — eventually runs into the same wall: device-side geofencing does not scale. Here is the architecture that replaces it, and why the replacement is not optional past a certain point.

The Trap: Device-Side Geofencing

Both major mobile platforms let an app register geofences for the OS to monitor in the background, waking the app when the device enters or exits a region. It is efficient, battery-friendly, and genuinely the right tool — for a small, fixed number of regions per user.

The problem is the cap. iOS limits an app to roughly 20 simultaneously monitored regions (CLRegion monitoring). Android's equivalent Geofencing API has a comparable ceiling. That is fine if your product tracks one home and one work location. It falls apart the moment a user can follow more than a handful of businesses, subscribe to more than a handful of alert zones, or interact with a marketplace where the number of "interesting" locations is unbounded.

If your product has any of that shape, device-side geofencing is not a viable primary mechanism — it's at best a secondary optimization layered on top of a server-side system.

Server-Side Matching with PostGIS

Move the actual matching problem to the backend. Store consumer locations (updated periodically, with consent, at whatever cadence your battery/privacy budget allows) and active deal/alert radii in PostgreSQL with the PostGIS extension. When a new event needs to check for nearby users, run a spatial query using ST_DWithin, which efficiently tests whether points fall within a given distance of each other using the database's native spatial indexing.

This shifts geofencing from "the OS wakes my app when I cross a boundary" to "the backend, which has global visibility across all users and all active radii, computes the match set the instant a new event is posted." It scales with your database, not with a per-device OS limit.

Geohash Partitioning: Don't Full-Table-Scan Every Broadcast

A naive ST_DWithin query against every registered user location on every deal broadcast works fine at small scale and degrades badly at real scale — you're paying a full-table scan cost on every single event. Geohash-based spatial partitioning fixes this: bucket users into geohash cells, and when a new event fires, only query the cells that could plausibly be in range, rather than the entire user base.

This is the difference between an architecture that works in a demo and one that survives a load test at several thousand concurrent users with continuous event traffic.

Real-Time Broadcast: WebSocket or SSE, Not Polling

Once a match set is computed, the delivery path matters as much as the matching itself. Push new events into the matching pipeline the instant they're created via WebSocket or Server-Sent Events — not on a polling interval. Polling adds latency proportional to your poll interval and wastes resources on empty checks; a push-based broadcast reacts the moment an event exists.

Push Delivery: FCM + APNs, With an Offline Fallback

The final hop — getting the alert onto the user's device — runs through the platform-native push services: Firebase Cloud Messaging for Android and web, Apple Push Notification service for iOS. Neither guarantees instant delivery under all network conditions, so build an offline fallback: queue notifications for devices that are unreachable at broadcast time, and deliver them on reconnect rather than silently dropping them.

A useful target to design and load-test against: notification delivered within 60 seconds of the triggering event, under your expected concurrent-user load. That number should come from an actual load test at a specific, confirmed concurrency target — not a guess. A ballpark range like "500 to 5,000 users" spans genuinely different infrastructure decisions (connection pooling, read replica strategy, queue partitioning) at each end; pin the number down before architecture, not after.

Multi-Location Fan-Out Without Duplicate Alerts

If a single event can apply to multiple source locations (a business with several branches posting one promotion, for example), the matching engine needs to evaluate each location's radius independently but still emit exactly one notification to a user who happens to be in range of more than one. Handle this with de-duplication at the notification-assembly stage — aggregate all matched-location results per user before dispatch, not per location.

Common Mistakes

1. Relying on device-side geofencing as the primary mechanism. Fine for a handful of fixed regions, unusable past the OS-imposed cap on simultaneous monitored zones.
2. Running spatial queries without geohash (or equivalent) partitioning. Works in a demo, collapses under real broadcast volume.
3. Polling for new events instead of pushing them into the pipeline. Adds unnecessary latency and wastes compute on empty checks.
4. Sending a duplicate notification per matched location instead of de-duplicating per user. Feels like a small bug until your top power-users — the ones following the most businesses or zones — are the ones getting spammed.
5. Committing to a load-test target without pinning down a real number. "500 to 5,000 concurrent users" is not a specification; it's two very different infrastructure builds.

---

Building a location-based product that needs real-time matching at scale? Ortem Technologies' mobile app development practice has architected PostGIS-based geofencing engines, push notification pipelines, and load-tested real-time matching systems for consumer marketplace apps. See our related case study on a real-time geofenced deals marketplace or book an architecture review →.