Event-Driven Quick Commerce Platform for a Hyperlocal Delivery Brand: Sub-20-Minute SLA, Real-Time Rider Tracking, and Zero-Timeout Order Processing
About This Project
A growth-stage quick commerce startup based in India, targeting dense urban and semi-urban corridors with a hyperlocal dark store model. The client needed a complete technical platform — installable customer app, rider app, and dark store management dashboard — capable of guaranteeing sub-20-minute delivery at peak order load without manual dispatch intervention or system degradation.
The Problem
India's quick commerce sector reached $3.65 billion in 2026, growing at 17% annually — the fastest rate globally. But market momentum means nothing if the operational infrastructure can't support the brand promise underneath it.
The client — a growth-stage quick commerce brand targeting dense urban corridors in India — had exactly that problem. At early volumes, a patchwork of WhatsApp threads, phone calls, and manual spreadsheets got orders out the door. When weekend peaks hit, the cracks showed: orders slipped through chat threads, riders got assignments minutes late, and neither ops staff nor customers had any live visibility into delivery status.
The core problem wasn't speed — it was the absence of a system that could make speed repeatable. Over 80% of buyers cite real-time tracking as a direct driver of loyalty to a delivery brand. The client had neither the tracking nor the system underneath it. Every sub-20-minute delivery was a manual heroic act, not a repeatable outcome.
Our Approach
We scoped the engagement as a complete platform build: customer app, rider app, and dark store dashboard — all backed by an event-driven pipeline designed to absorb peak-hour surges without degradation or manual fallback.
Off-the-shelf delivery management software was ruled out in the first week. Those tools are designed for last-mile logistics at city scale — not for a dark-store model where the customer-to-store radius is 2–5 km and the SLA is 20 minutes. Purpose-built was the only viable path.
Stack decisions followed immediately: Medusa.js for the commerce layer (order lifecycle, inventory, fulfillment), Strapi for the ops admin surface, BullMQ over Redis as the job queue backbone — decoupling order intake from order processing to absorb burst load without blocking. PostGIS for geospatial routing: delivery zone polygons, nearest dark store lookup, proximity-based rider dispatch. Socket.io for real-time event streaming to customer and rider surfaces simultaneously. Full observability on GCP via Sentry, PostHog, Prometheus/Grafana, and Jaeger.
Architecture & Technical Solution
<ArchitectureDiagram>[SVG architecture diagram — see attached file]</ArchitectureDiagram>
The platform runs as a Turborepo monorepo with four distinct surfaces sharing types, utilities, and deployment pipelines.
The Customer PWA is an installable Next.js app with Workbox-powered offline support — customers can browse and order without App Store friction, and the service worker caches product catalogs so the last known state persists when connectivity drops.
The Rider PWA is a separate installable Next.js app with GPS tracking, assigned order queue, turn-by-turn address guidance, and SQLite offline storage that syncs on reconnect. Connectivity gaps during delivery no longer cause data loss or duplicate assignment.
The Dark Store Dashboard is a Strapi-powered admin surface where store staff see incoming orders via Socket.io push in real time. Inventory discrepancies are flagged before an order is accepted — not discovered at pack time.
The critical architectural decision was in the Commerce + Queue Backend: separating order intake from order processing. Every incoming order hits a lightweight endpoint and enters BullMQ in under a second. A dedicated worker pool handles the rest asynchronously — inventory lock, PostGIS dark store assignment (nearest delivery polygon match), rider proximity check, ETA calculation, and Socket.io status emission. This decoupling means 10x peak traffic spikes produce zero blocking timeouts.
PostGIS geometry queries run against indexed columns in Cloud SQL and return in under 100ms — fast enough to complete before the customer sees "order confirmed."
Build & Deployment
The project ran over 6 months across architecture, core build, and production hardening phases. The hardest engineering problems were in the failure modes, not the happy path: rider app disconnects mid-delivery, inventory mismatches discovered post-acceptance, and GPS coordinates landing on delivery zone polygon boundaries.
Solutions: SQLite on the rider PWA for full offline resilience with server sync on reconnect; optimistic inventory locks held for 90 seconds from acceptance; a polygon boundary resolver that assigns ambiguous coordinates to the nearer store centroid by Euclidean distance to store reference points.
Deployment runs on GCP Cloud Run (containerised, auto-scales to zero between peaks) with Cloud SQL for PostgreSQL+PostGIS, Upstash Redis, and Vercel for the frontend surfaces. GitHub Actions handles build, test, and deploy on every merge to main.
Results & Impact
<MetricsDiagram>[SVG metrics panel — see attached file]</MetricsDiagram>
The platform went live across all four surfaces handling real production orders from day one. The architectural bet paid off immediately: no queue timeouts during the first high-traffic weekend, rider dispatch automated from a 5–8 minute manual call down to under 4 seconds, and zero missed orders attributable to system failure.
Before: every sub-20-minute delivery required manual coordination — a dispatcher calling a rider, a rider calling back to confirm the address, an ops manager checking WhatsApp to verify pickup. After: the platform handles dark store assignment, rider dispatch, and live customer updates without human intervention from order placement to handoff.
The platform made the sub-20-minute SLA a systemic outcome rather than a heroic act — the single architectural shift that enables geographic expansion without scaling the dispatcher headcount alongside it.
"Before this platform, every fast delivery was a miracle. Now it's the baseline." — Operations Lead, anonymised
Tech Stack
| Layer | Technology |
|---|---|
| Frontend | Next.js (App Router), Workbox (offline PWA) |
| Rider App | Next.js PWA, SQLite offline sync |
| Commerce | Medusa.js |
| CMS / Admin | Strapi |
| Queue | BullMQ (Redis-backed) |
| Database | PostgreSQL + PostGIS (GCP Cloud SQL) |
| Cache | Redis (Upstash) |
| Real-time | Socket.io |
| Infrastructure | GCP Cloud Run, Vercel |
| Monorepo | Turborepo |
| Observability | Sentry, PostHog, Jaeger, Prometheus + Grafana |
Want a Solution Like This?
If you're building a hyperlocal delivery brand, a q-commerce platform, or any real-time fulfilment product — and you need a system that actually holds up at peak load — we scope, architect, and ship it fast.
Book a free 20-minute scoping call → We scope, prototype, and deliver — faster than you'd expect.
Built by Vertical Idea · June 2026 · Logistics · 6 months
Project Details
- Sector
- Logistics
- Timeline
- 6 months
- Engagement
- TurboMart
Tech Stack
Next.jsTurborepo
Medusa.js
StrapiBullMQPostGISSocket.io
GCP Cloud Run
Redis
VercelSentryPostHogWant Results Like This?
Tell us what you're building. We'll scope it, price it, and ship it — faster than you expect.
We respond within 24 hours. No sales pitch — just a straight conversation about your project.