Dravya RO
On-Demand Service & Field Logistics Platform
Geospatial dispatch for an on-demand water-purification service network — 3 apps, one backend, near-zero manual dispatch.
Overview
The story behind it
Dravya RO runs an on-demand water purification service: customers book a service, the platform dispatches the nearest qualified technician, and the job is tracked, paid, and settled end-to-end. I built the centralized backend that powers all three mobile applications — Customer, Technician, and Admin — on Node.js, Express.js, and MongoDB.
The heart of the system is geospatial matching. Service requests carry coordinates; technician profiles carry geo-indexed service areas and live availability. A $nearSphere query over a compound geospatial index matches incoming requests to the closest qualified technician in milliseconds, collapsing what used to be a manual phone-call dispatch process into an automatic, auditable allocation.
Payments were the second hard problem. The business needed prepaid online checkout and post-service settlement in the same flow, with per-job commissions computed automatically. Razorpay's split-payment architecture handled the money movement; a per-job ledger tracks commissions, refunds, and cash settlements so the ops team can reconcile every rupee.
What it does
Key features
- Three-app backend — Customer, Technician, and Admin apps share one versioned REST API surface
- Geospatial dispatch — $nearSphere matching with technician availability, skills, and service-area filters
- Razorpay split payments — prepaid online checkout plus post-service settlement with automated per-job commissions
- Real-time job lifecycle — FCM push notifications drive state changes from booking to completion
- Secure onboarding — 2Factor mobile OTP verification with granular role-based access control
- Ops ledger — per-job commission tracking, refund handling, and cash-settlement reconciliation
How it's built
Architecture & implementation
- Technician collection carries a 2dsphere index on service location plus compound indexes on (skills, availability) for filtered near queries
- Job state machine (booked → assigned → en-route → in-service → completed → settled) enforced server-side with guarded transitions
- Razorpay payment links and webhooks drive the settlement ledger; webhook signatures are verified before any state mutation
- FCM device groups per user role keep notification fan-out cheap and reliable across the three apps
- OTP sessions are rate-limited and single-use; refresh tokens rotate on use to lock down long-lived mobile sessions
- Deployed on AWS EC2 with Nginx reverse proxy and PM2 cluster mode; structured logs per job id make support traceable
Highlights
Engineering highlights
- MongoDB $nearSphere geospatial indexing for nearest-technician matching
- Razorpay split payments: prepaid online + post-service settlements with automated per-job commission tracking
- Real-time FCM notifications with 2Factor OTP onboarding and granular RBAC
Takeaways
Lessons learned
- Geospatial queries are only half the answer — availability and skill filters must sit in the same compound index or dispatch falls apart under load
- Payment integrations live or die on webhook idempotency; designing for at-least-once delivery early prevents duplicate settlements
- A single versioned API serving three apps forces disciplined contract versioning — and that discipline pays back immediately