An event-driven route planner for instant delivery that eliminates idle wait time by sequencing pickups based on real-time store prep times, item availability checks, and live traffic — so a single partner handling multiple orders never waits outside a shop while other ready orders sit uncollected.
Architecture
Problem it solves
In instant delivery, partners pick items directly from shops and deliver in real time — unlike traditional ecommerce where everything ships from a warehouse. When multiple users place multiple orders and one partner handles all of them, poor planning kills efficiency. For example: User 1 orders ramen (20 min prep) and medicines (instant). User 2 orders apples, diet coke, chocolates (instant). User 3 orders noodles (10 min) and pastry (10–20 min). Without smart sequencing, the partner ends up waiting 20 minutes outside the ramen shop while medicines and User 2's entire order are ready to go. The problem isn't just distance — it's that prep time, availability, and route are never considered together.
How it works
Every incoming order fires an event that the orchestrator picks up. Each order gets its own vendor agent worker that contacts the store via SMS, call, or WhatsApp to validate item availability and get an accurate prep ETA. Once availability is confirmed, the route planner kicks in and computes the optimal pickup sequence using OSRM — accounting for shop location + prep time + distance + traffic + nearby orders. If multiple users fall on the same route, deliveries happen along the way instead of separate trips. While ramen is being prepared, the partner can pick up User 2's instant order and grab noodles/pastry for User 3 depending on their readiness. If something fails — no store response, item unavailable — the system falls back to ops instead of silently failing. Everything runs async using BullMQ + Redis so workers don't block each other.
Approach
Instead of treating routing as a pure distance problem, I built it around the reality that instant delivery is a time + availability + location problem. The orchestrator acts as the brain and decides what runs when — availability checks happen in parallel before any routing decision is made, because there's no point optimizing a route for an item that isn't in stock. I used OSRM for real routing calculations, PostgreSQL with Prisma for order and state management, and BullMQ + Redis for async worker orchestration so the pipeline stays non-blocking at scale. The frontend is React + Vite with Leaflet for live map visualization of routes and partner locations.