Design a Local Delivery Service: Quick Commerce Without Overselling

Customers browse products, but the list is limited to products that a nearby warehouse both holds and can deliver within the promised window. A product sitting on a shelf across the city is irrelevant, so location is part of every catalogue query. Customers then place an order containing several products and pay for it. The whole cart is accepted together or rejected together; a half-confirmed basket would be confusing and hard to fix.

After ordering, the customer tracks progress from packing through to the rider's live position on a map. Rider earnings, discount campaigns and warehouse replenishment are real parts of the business but are excluded here so the discussion stays on availability, reservation and tracking.

Availability lookups need to be very fast, assume under 100 ms, because stock information appears on the home screen, category pages, search results and the cart. If that check is slow, every screen is slow. Orders, on the other hand, demand strong consistency: the system must never confirm a product that is not physically on the shelf, because a missing item becomes a refund, an angry customer and a wasted rider trip.

Demand is spiky. Evening hours and festival sales can bring roughly five times normal traffic, so the design must scale out without manual intervention. Tracking must feel live, which in practice means the rider's position refreshes about every five seconds. Faster is possible but quickly becomes expensive in battery and server load for little visible benefit.

Assume about 1,000 dark stores, each carrying roughly 5,000 products, which gives about 5 million inventory rows. That is a small dataset. Assume 2 million orders per day, which averages only about 23 per second and perhaps 120 per second at peak. Order writes are therefore modest.

Availability reads are a different story. Because nearly every screen shows stock, assume around 100 million availability reads per day: roughly 1.2K per second on average and near 6K per second at peak. Add a fleet of 20,000 riders each reporting GPS every five seconds, and location updates reach about 4K per second. The lesson is that reads dwarf orders, so availability should come from a fast cache, and the system should apply strict checks only at the moment of checkout.

Four entities describe the domain: an item in the catalogue, a warehouse, the inventory that records how many units of a given item a particular warehouse holds, and the order. Modelling inventory as its own entity, keyed by warehouse and item, is what allows per-store stock to be cached and updated independently.

Browsing uses GET /items with the customer's lat, lng and an optional query q, returning only items in stock nearby. Checkout is POST /orders with a list of item IDs and quantities, a delivery address and payment details, returning an order_id, a status and an estimated arrival time. Tracking uses a WebSocket at /orders/{id}/track that streams status transitions and rider coordinates, since polling for a position that changes every few seconds would waste requests.

The customer app connects through an API gateway for authentication and routing. Browse requests go to an availability service, which works out which warehouses serve the customer's location and reads per-store stock counts from a Redis cache. Checkout requests go to an order service, which reserves inventory inside a single Postgres transaction, since Postgres holds the authoritative stock counts.

Every committed stock change also flows back into the Redis cache so browsing stays close to reality. Confirmed orders are published to Kafka as events. A delivery service consumes those events, assigns a nearby available rider, and receives that rider's GPS position every five seconds from the rider app. It then forwards the order status and the rider's location to the customer over a WebSocket.

Using an event stream between ordering and delivery means a slow dispatch step never blocks checkout, and other consumers such as notifications or analytics can consume the same events without any change to the order service, which keeps that critical path small.

The first step happens offline: each warehouse is assigned a delivery zone, a polygon covering the area a rider can reach in roughly fifteen minutes using real road travel times rather than straight-line distance. A river or a highway with few crossings can make a nearby address unreachable in time, and the polygon captures that.

At request time, the customer's address is converted to a geohash cell, and a precomputed table maps each cell to the warehouses whose zones cover it. Finding candidate stores is therefore a single key lookup instead of a costly point-in-polygon query. For each candidate store, Redis holds a map of item to available quantity, and the service shows only items with stock above zero. When more than one warehouse covers the customer, it prefers the nearest store able to fulfil the entire cart, so the order ships from one place.

Freshness comes from streaming every reservation and restock into the cache within a second or two. The cache may occasionally be slightly behind, and that is acceptable here because checkout performs the authoritative check against the database. Fast and approximate for browsing, exact at payment time.

The naive checkout reads the current quantity, confirms it is sufficient, then writes the reduced value. Between the read and the write, a second customer can read the same quantity, and both orders succeed for one remaining unit. Under evening load that race is not hypothetical; it happens regularly.

A distributed lock per item, for instance in Redis, closes the race but adds another system to operate, and a lock that expires mid-checkout can still let two buyers through. The chosen approach lets the database enforce the rule atomically with a conditional statement such as UPDATE inventory SET qty = qty - n WHERE item_id = ? AND store_id = ? AND qty >= n. If zero rows change, that item is unavailable. Running one such statement per cart line inside a single transaction means the whole basket is reserved or none of it is.

Reserved units are held while payment completes, with a timeout of around ten minutes; if payment fails or expires, a background job returns them to available stock. Every checkout request also carries an idempotency key, so when a flaky mobile network causes the app to resend, the server recognises the duplicate and returns the original order instead of creating a second one.

Each rider app reports its coordinates every five seconds, around 4K writes per second across the fleet. These updates are frequent and individually low-value, so they are not written to the main relational database. Instead Redis keeps just the most recent position under one key per rider, and Redis GEO commands let the dispatcher quickly locate idle riders close to a warehouse when a new order arrives.

To reach the customer, the WebSocket server handling that customer's connection listens on a pub/sub channel for their order and relays each new position as it arrives. Order progress is modelled as a small state machine moving from placed to packed to picked up to delivered, and every transition is published as a Kafka event so push notifications and support tools stay in sync. A background process also archives the full location trail to inexpensive storage, where it helps resolve delivery disputes and train arrival-time prediction models.

Serving browse pages from cached stock keeps the app fast, but now and then a product disappears at checkout because the cache lagged; the app can then offer a substitute. Relying on a conditional database update rather than a Redis lock is simpler and correct, though a single very popular item forces concurrent buyers to queue on one row.

The reservation timeout is a tuning knob: a longer hold reduces payment failures caused by slow banks, while a shorter hold puts unpaid stock back on the shelf sooner. The tracking interval is another: five seconds looks smooth on a map, and anything faster spends rider battery and server capacity for little gain. The unifying principle is to give browsing fast, slightly stale reads and to keep checkout strict and atomic.