If you are an engineer scoping a food delivery build, here is the reframing that will save you a year of misdirected effort: the customer app is the easy part. Search, cart, checkout, tracking UI — all solved, all commodity. The system that decides whether the business is solvent is the backend that assigns couriers, predicts arrival times, and never double-charges anyone. That is where the hard distributed-systems problems live, and it is where your senior engineering time should go.
Everything downstream of this backend is an economics problem in disguise. Every idle courier minute, every mispredicted ETA, every duplicate refund is a margin leak, and margins on a single order are only a few dollars wide. The engineering goal is not "ship the features" — it is to make each order measurably cheaper to fulfill without breaking correctness. Let me walk through the subsystems that matter.
The Dispatch Engine Is the Product
When an order is created, one decision dominates your unit economics: which courier gets it? The naive implementation — nearest available courier by straight-line distance — is trivial to write and expensive to run, because it ignores everything that actually determines cost.
A real dispatch engine is a constrained real-time optimizer. For each incoming order it evaluates candidate couriers against:
- Batchability — is a courier already carrying an order whose route and drop-off make a second pickup cheap?
- Predicted prep time — dispatching before the kitchen is ready just converts courier time into idle time at the counter.
- Live traffic and direction of travel — a courier heading toward the restaurant beats a closer one heading away.
- Zone supply/demand balance — pulling your last courier out of a heating-up zone can cost more than the trip earns.
This is an assignment problem you re-solve continuously as state changes. In practice it runs as a service consuming an event stream of order and courier state, scoring candidates with a model, and emitting assignment events. Building it well is where machine learning and AI engineering earns its budget — batching two or three orders into one trip is frequently the whole difference between a profitable zone and a loss-making one.
Real-Time Location Is a Pipeline, Not an Endpoint
Courier tracking looks like a feature and is actually an ingestion pipeline. Thousands of devices emit GPS pings on an interval; you need to ingest, smooth, map-match, and fan those out to customer tracking screens and the dispatch engine — under a latency budget, during a dinner-rush surge, without falling over.
The pragmatic shape is an event-driven backend with a message queue decoupling ingestion from consumers. Location writes hit a hot store optimized for high write throughput and short-TTL reads; the dispatch engine and ETA models subscribe to the same stream. Keep the write path dumb and fast, and push smoothing and map-matching to stream processors so a spike in ping volume degrades gracefully instead of blocking order creation.
Geospatial Modeling You Cannot Retrofit Cheaply
Two architectural decisions are painful to change once you are live at volume, so make them deliberately up front.
The first is geospatial indexing. "Which restaurants are near me" and "which courier is closest" run through it on every screen and every dispatch cycle. A naive query that scans and computes distance over every row will buckle the first time a zone gets busy. You want a spatial index — geohashing, an H3-style hex grid, or your database's native spatial type — so proximity lookups stay bounded as data grows. Get this wrong and every hot zone becomes a full-table-scan incident.
Idempotency Is Not Optional
The second decision is idempotency across the order pipeline. Networks drop, users double-tap "Place Order," and payment gateways retry callbacks. Every step from order creation through dispatch to payout must tolerate being received twice without charging twice, dispatching twice, or paying a courier twice.
Concretely: attach an idempotency key to order creation and payment operations, dedupe on it at the service boundary, and make state transitions safe to replay. Consume payment and dispatch events with dedup on event IDs. This is unglamorous plumbing, but skipping it produces the exact class of silent, margin-eating bug that is hardest to unwind once you have volume — duplicate charges, ghost dispatches, reconciliation nightmares that surface days later in the payout run. If you want the business framing around all of this, read the full guide on TechCirkle.
The ML Models That Move the Numbers
Three models carry most of the economic leverage, and they are distinct engineering investments:
- ETA prediction. The promised delivery time is a financial commitment — under-promise and you refund, over-promise and the cart is abandoned. Train it on restaurant prep patterns, courier availability, and live traffic. It is probably the highest-leverage model in the system because it protects both conversion and margin at once.
- Demand forecasting. Predict a spike in a zone at a given time and pre-position couriers before orders land, converting reactive dispatch into proactive supply and cutting idle time.
- Fraud / anomaly detection. Refund abuse, promo stacking, fake accounts, and reorder-cancel loops are a recurring tax on margin. An anomaly model surfaces the few percent worth human review instead of forcing you to inspect everything.
All three depend on clean event data flowing off the same pipeline that feeds dispatch, which is another reason the event backbone is the foundation everything else stands on.
Designing for the Friday-Night Spike
Delivery traffic is inherently bursty — mealtimes, weekends, and weather produce sharp surges, and the moment your platform slows at peak dinner is the moment you lose the orders that pay for everything. Design for a 5x spike as a normal condition, not an incident.
That means horizontally scalable, stateless services behind autoscaling; a message queue to absorb intake bursts and decouple order creation from fulfilment; and cross-platform clients (React Native or Flutter) so one team ships the three mobile surfaces without tripling front-end cost. The heavy engineering stays server-side, which is why the custom backend work matters far more than the mobile shell. Load-test against synthetic surge traffic before launch, not after.
Frequently Asked Questions
Why is nearest-available-courier a bad dispatch strategy?
It optimizes a single variable — distance — while ignoring the ones that actually drive cost: batchability, real kitchen prep time, traffic, direction of travel, and zone supply balance. It also forgoes batching, which is often the entire margin difference between a profitable and unprofitable zone. Dispatch is a continuous constrained optimization, not a proximity lookup.
How do I make the order pipeline idempotent in practice?
Attach an idempotency key to order-creation and payment requests and dedupe on it at the service boundary, so retries and double-taps collapse to one effect. Consume downstream payment and dispatch events with deduplication on event IDs, and design state transitions to be safe to replay. The goal is that receiving any message twice never charges, dispatches, or pays twice.
What breaks first when geospatial queries aren't indexed?
Proximity queries — "restaurants near me" and "closest courier" — degrade to full scans that recompute distance over every row. Under a busy zone that turns into CPU-bound database incidents exactly when traffic peaks. A spatial index (geohash, H3 hex grid, or a native spatial type) keeps those lookups bounded as data and load grow, which is why it is an early, hard-to-retrofit decision.
How do real-time tracking systems handle surge load?
Treat tracking as an ingestion pipeline, not an endpoint. Decouple GPS ingestion from consumers with a message queue, keep the write path fast and dumb into a high-throughput hot store, and push smoothing and map-matching into stream processors. That way a spike in ping volume degrades gracefully and never blocks order creation on the critical path.
Which ML model gives the best return first?
ETA prediction, in most builds. It protects conversion (accurate promises reduce cart abandonment) and margin (fewer refunds from missed times) simultaneously, and it sharpens dispatch decisions. Demand forecasting and fraud detection follow closely, but they all depend on clean event data from the same pipeline, so build the event backbone before the models.
Native or cross-platform for the three apps?
Cross-platform (React Native or Flutter) is the pragmatic default for customer, restaurant, and courier apps — one team ships iOS and Android without tripling front-end effort. The differentiating engineering lives server-side in dispatch, the location pipeline, and the ML layer, so that is where custom investment pays off rather than in platform-specific mobile code.
Top comments (0)