Design 10-minute grocery delivery (Zepto / Blinkit)

Overselling is the worst failure in quick commerce: the user paid, and the picker finds an empty shelf. The fix has two parts. First, accurate counts: every pick, receipt, damage and cycle-count is an event that updates on_hand in the store's partition; a store team does daily cycle counts of fast movers and the system flags SKUs whose sales stopped suddenly (often a phantom stock sign). Second, safe reservation: at checkout, run one Redis Lua script per store that checks available = on_hand - reserved for all cart items and increments reserved only if all pass. Because a store's keys live on one Redis shard (hash tag {store_id}), the script is atomic and fast, a few hundred microseconds. The reservation has a TTL; a sweeper releases expired ones, and payment success converts it to a committed decrement written to Postgres. Redis is not the source of truth: a sync worker rebuilds Redis counts from Postgres on startup and checks drift every few minutes. Also keep a small safety buffer (e.g. show out of stock when available is 1 for items with frequent count errors), trading a little lost sales for far fewer missing-item refunds.

The 10-minute promise is three parts: wait for a picker, pick and pack (~2-3 min), and ride (~4-6 min for 2 km in a city). The ETA service computes each part from live signals in Redis: pending picks divided by active pickers times average pick time, the number of idle riders and riders returning, and travel time from a routing service with time-of-day traffic. A gradient-boosted model trained on stage timestamps corrects bias by store and hour. When the predicted ETA crosses a threshold, the store must protect its promise instead of breaking it for everyone: raise the delivery fee (surge), show a longer ETA, shrink the store polygon temporarily, or mark the store 'busy' and stop accepting orders for a few minutes. This is load shedding at the business level, and it must happen per store, because one store in heavy rain can be overloaded while its neighbour is idle. Track promise accuracy (percentage delivered within shown ETA) as the key SLO.

Unlike food delivery, riders here start from the same place: the dark store. So dispatch is mostly a queue problem, not a matching problem across a city. Riders who finish a delivery head back and join the store's idle queue. The dispatcher assigns when the pick is about 60% complete, picking the rider who will be at the store soonest, so neither the bag nor the rider waits. Batching two orders is allowed only when both drop points are in the same direction and the second customer's promised ETA still holds; the dispatcher simulates both routes before batching. During spikes, the system can borrow riders from a nearby store whose load is low, at the cost of a longer first leg. Rider location updates (~5k/s) go to Redis GEO for the latest point and to Kafka for history; the WebSocket gateway pushes updates to customers watching the order.

The dark store is a physical operation that cannot stop because of a cloud blip. Picker and rider apps keep a local queue of actions (scans, item missing, handover) and retry with idempotency keys, so a brief outage does not lose events. A small edge service or a cached pick list on the device lets pickers continue the orders they already have. The order service rejects new orders for a store whose heartbeat is stale, so we never accept orders a store cannot see. Each store is an independent unit in the data model (partitioned by store_id), which also lets you roll out changes store by store.

Row locks with SELECT ... FOR UPDATE in Postgres are simple and durable but slow under hot items like milk and bread at 8 am. Redis Lua scripts give atomic multi-item reservation in microseconds; the cost is a second copy that can drift, so you need reconciliation from Postgres. At a few orders per minute per store either works, but sale and rain spikes favour Redis.

A safety buffer hides items with one or two units left. You lose some sales, but a missing item after payment costs a refund, a bad rating and picker time. Tune the buffer per SKU from its count-error history.

Assigning at order time makes riders wait idle at the counter; assigning after packing makes bags wait. Assigning at around 60% of the pick, based on predicted remaining pick time, balances both.

Serving each location from exactly one store keeps inventory and dispatch simple and fast. The cost is a smaller assortment; some apps add a slower 'more items' option from a larger warehouse as a separate order.

Orders jump 5-8x within minutes while riders slow down. Admission control per store (surge fee, longer ETA, temporary polygon shrink) is the main defence; autoscale stateless services on request rate and keep Redis well under its CPU limit.

Thousands of reservations for a few SKUs in one store hit one Redis shard. Still fine at a few hundred ops/s; at 10x, keep reservations per store small and fast, and move non-critical reads (catalog flags) to replicas.

Stock flags change every few seconds, so caching whole pages is hard. Cache the static catalog per store at the CDN and fetch stock flags as a small separate call.

The reservation is still held with TTL. A payment webhook consumer creates the order idempotently from the payment intent; if stock was released by then, it refunds automatically. Reconciliation with the gateway's settlement report catches any gap.

Failover to the replica; counts may be a few writes behind. Pause checkout for affected stores for a few seconds, rebuild counts from Postgres (on_hand minus active reservations), then resume.

The picker app marks it missing; the system offers a substitute or refunds that item immediately, decrements on_hand to zero and triggers a cycle count for that bin.