Real-Time Systems
Designing Real-Time Location Tracking Services
GPS write volume, Redis GEO hot paths, freshness budgets, and how to keep location pipelines from starving product APIs under production load — for field ops, logistics, and multi-sided platforms.
SystoBase Engineering · · 15 min
Key takeaways
- Treat location as a heartbeat with explicit TTL — not infinite history on every ping.
- Industry pattern: synchronous DB write per ping; SystoBase recommendation: Redis GEO hot store with batched archival to PostgreSQL/PostGIS.
- Separate ingestion from dispatch reads to protect ride API latency.
- Define freshness SLOs per use case: dispatch vs rider map vs fraud.
- Monitor update lag, drop rate, and GEO command latency.
- Background location on mobile requires different batching rules than foreground.
Location as heartbeat
Location feeds matching, ETA, live maps, fraud heuristics, and operations dashboards. It is not a single CRUD field — it is a high-volume stream with product-specific freshness budgets. Driver and courier tracking in mobility and logistics are common instances; the service design is the same wherever online supply must stay fresh under concurrent writes.
Every online driver can emit updates every few seconds while moving. Multiply by concurrent online drivers and you have a write problem that will dominate API capacity if routed through the same handlers as ride creation.
Industry pattern: reuse the ride update endpoint for location. SystoBase recommendation: dedicated lightweight ingestion endpoint or gateway with authentication, rate limits per device, and schema validation before touching hot stores.
The write path
The ingestion path should validate coordinates, timestamp, accuracy, and driver session before write. Reject impossible jumps unless you have explicit teleport rules (e.g., simulator testing).
Buffering on device reduces chatter on poor networks — batch points with monotonic sequence numbers so the server can discard duplicates idempotently.
Failure mode: location write storms during large events overload PostgreSQL when every ping is transactional. Hot path writes belong in memory-first stores; archival can lag seconds without breaking dispatch if TTL semantics are clear.
Redis GEO hot store
Redis GEO stores lat/lon in sorted sets optimized for radius queries. GEADD updates a driver position; GEORADIUS retrieves nearby drivers for dispatch. This pattern is industry-standard for online supply at scale.
Pair GEO with key TTL or explicit offline removal when drivers go offline — otherwise ghost drivers linger in radius results until manual cleanup.
SystoBase recommendation: namespace keys by city or shard to keep radius queries bounded, and store last_updated_ms alongside GEO entries in a hash for freshness filtering before PostgreSQL eligibility checks.
Freshness budgets
Dispatch may accept location up to 15–30 seconds stale under defined rules; rider live maps may want fresher data; fraud checks may need trail history. Document these budgets per consumer.
Industry pattern: one global freshness threshold. SystoBase recommendation: consumer-specific filters at read time using last_updated metadata, not separate write pipelines unless volume demands it.
Stale location causes bad matches and angry riders. Alert when median age of online driver locations exceeds SLO — often a mobile release regression or CDN edge issue.
Persistence and trails
Not every ping belongs in permanent storage. Trip trails for billing disputes need sampled or simplified polylines in PostgreSQL with PostGIS line types; raw 1 Hz logs explode storage.
Industry pattern: store everything forever. SystoBase recommendation: tiered retention — hot Redis, trip-bound trail in PostgreSQL for active/completed rides, cold archive for analytics with aggregation.
PostGIS supports spatial analytics on historical trips: average speeds in corridors, pickup zone heatmaps, route deviation detection. Keep analytics queries off production OLTP replicas.
Delivery to clients
Riders tracking assigned drivers need low-latency updates. Options include polling driver location endpoints, WebSocket channels, or SSE. Choice depends on concurrent subscribers and ops complexity — covered in depth in our WebSockets vs polling article.
Fan-out from one driver update to one rider is cheap; broadcast to many operators watching a fleet is not. Separate channels and authorization per ride_id.
Never leak other riders’ driver positions through predictable IDs or missing authZ on location endpoints — a common penetration finding.
Monitoring and failure modes
Track ingest rate, error rate, p95 GEO latency, median location age, and offline cleanup success. Correlate spikes with app version rollouts.
Failure modes: Redis memory pressure evicting GEO keys, clock skew on devices, drivers stuck “online” after OS kill, partition between Redis and PostgreSQL availability state.
Runbooks should include “flush ghost supply” procedures with audit — mass offline events affect marketplace liquidity.