Building a Delivery Orchestration Layer

Marketplace delivery looks simple on a slide: "assign nearest driver." In production you need presence, scoring, offers, reassignment, GPS freshness, and an ops story when something sticks. Here is the architecture pattern we use for a food-delivery platform's delivery orchestration service.

Separate orchestration from order and driver apps

Keep responsibilities clear:

Orchestration consumes order events and produces assignment / soft-offer events. Drivers and customers should not embed Haversine loops.

Presence with Redis GEO

Drivers update location on a short interval (for example every ~10 seconds when online). Redis GEO commands are a cost-effective fit:

• GEOADD for latest coordinates
• GEORADIUS / GEOSEARCH for nearby drivers
• TTL or explicit delete when a driver goes offline

Pair Redis presence with durable driver records in DynamoDB (or your primary store) for attributes that should survive a Redis flush: vehicle type, capacity, rating bands, region.

Matching that stays honest

A practical first algorithm:

1. Query nearby online drivers within radius
2. Filter by eligibility (documents verified, correct region, not already busy)
3. Score by distance (Haversine) and simple business weights
4. Soft-offer to top candidate(s) with a timeout
5. On decline/timeout, offer next candidate; on accept, emit assignment

Sub-100ms matching is achievable when the hot path is Redis + in-memory scoring and you are not doing cross-region fan-out on every order.

Event-driven edges

Typical Kafka (or equivalent) flows:

• In: order paid / ready for dispatch
• Out: soft offer created, offer accepted/declined, delivery assigned, location-related ops events as needed

Make consumers idempotent. A redelivered "order ready" must not create five racing offers for the same order without a state machine.

Ops visibility

Engineers will ask "why is this order stuck?" Build for that:

• Order → offer → driver assignment timeline in an ops UI
• Clear states: searching, offered, assigned, picked_up, delivered, failed
• Metrics: time-to-first-offer, offer accept rate, reassignment count, GEO query latency
• Alerts on dispatch lag and consumer lag — not only HTTP 5xx

Cost-aware choices

For early scale:

• Self-host Redis on a small instance or use a managed tier sized to presence, not analytics
• Prefer event-driven wakeups over polling every client from the server
• Avoid multi-region orchestration until you have multi-region demand

Grocery and multi-stop (when you need it)

Food delivery is often single pickup → dropoff. Grocery and multi-merchant carts introduce batching and shopper workflows. Keep the orchestration API's core (presence + offer + assign) stable; extend with job types rather than forking a second dispatcher.

Closing

Delivery orchestration is a state machine with a map, not a CRUD table. Redis GEO for presence, events for assignment, idempotent consumers, and an ops timeline will carry you further than a clever scoring formula alone. Start with nearest-eligible + soft offers; deepen scoring when metrics say distance is not the bottleneck.