KACHIX

Pilgrimage travel · Kachix product

Safe — real-time pilgrim tracking for Hajj and Umrah

Mobile Application DevelopmentBackend, APIs & IntegrationsWeb Development
Safe — real-time pilgrim tracking for Hajj and Umrah — cover image

Challenge

Hajj concentrates millions of people into a few square kilometres, many of them elderly, most far from home, and a good number without a shared language with the people around them. A pilgrim who wanders from their group is not merely lost — in that density and that heat, they are at risk.

The people who need to know are not one audience but three, and they need very different things. A tourism company needs oversight across every group it is responsible for. A supervisor on the ground needs to find one specific person right now. A family at home needs reassurance, and nothing more — giving them operational controls would be both useless and unsafe.

Hardware makes it harder. A bracelet on a moving pilgrim has intermittent cellular coverage and a finite battery, so silence is ambiguous: it might mean nothing is wrong, or it might mean the one thing you needed to know about never arrived.

Solution

Our team built the pipeline event-first. Bracelets publish GPS, vitals, and button presses over MQTT with TLS into a dedicated ingestion service, which hands off to RabbitMQ rather than writing straight to a database. Workers then subscribe independently for alerting, geofence evaluation, offline detection, and escalation, alongside a Python worker that applies both threshold rules and anomaly detection to the vitals stream.

That separation is what makes silence legible. Because offline detection is its own subscriber rather than a side effect of a write, a bracelet that stops reporting raises an alert in its own right — the absence of data becomes an event instead of an empty screen.

Storage matches the shape of the data: PostgreSQL 16 with PostGIS for geofence geometry, TimescaleDB for the location and vitals time series, Redis for hot reads. The API serves REST for state and SignalR for the live push that a tracking map needs.

The three audiences became three clients over one backend — a React operations dashboard for the company, and Flutter supervisor and family apps built as separate flavours of one codebase. Role scoping is real, not cosmetic: family sign-in is phone plus OTP and lands on a read-only view of one pilgrim, while supervisors get tracking, passenger rosters, path playback, safe-zone drawing, and device health.

One deliberate constraint shaped the maps: no Google Maps key anywhere. Both clients render OpenStreetMap tiles — flutter_map on mobile, react-leaflet on web — which removes a per-request billing dependency from a product whose entire job is to keep a map open.

Results

The system runs end-to-end across all three clients: bracelet telemetry arrives over MQTT, workers evaluate it, and supervisors watch pilgrims move across a live map of Mina while families see a single reassuring view.

Alerts distinguish their cause — device offline, AI-detected anomaly, or a pressed panic button — and carry an explicit state through delivered, escalated, and acknowledged, so an unanswered alert is a visible condition rather than a message nobody happened to see. Device rosters surface bracelet battery level and staleness, which turns a quiet bracelet into something a supervisor can act on before it matters.

Delivery is gated in CI: container images fail the pipeline on vulnerability scanning rather than shipping and being patched later.

Safe — real-time pilgrim tracking for Hajj and Umrah — image 1 of 4
Safe — real-time pilgrim tracking for Hajj and Umrah — image 2 of 4
Safe — real-time pilgrim tracking for Hajj and Umrah — image 3 of 4
Safe — real-time pilgrim tracking for Hajj and Umrah — image 4 of 4
Supervisor and family apps running end-to-end against the stack. The red DEBUG ribbon is Flutter's debug-build banner, not part of the interface.

Want results like these? Tell us what you're trying to build.

Start a project