Local Delivery Service (Gopuff)

Instant delivery from nearby stock

Design a service that sells everyday items from the company's own small warehouses, shows each customer only what can reach them within an hour, and never sells the same unit twice.

Overview

A local delivery service runs its own small warehouses, called micro-fulfillment centers, in the neighborhoods it serves. It buys and stocks the items itself, so unlike a marketplace that shops from someone else's shelves, it knows exactly how many units sit in each center. A customer opens the app, sees the items that can reach them within the delivery promise, adds several to a cart and orders; a worker picks and packs the order and a driver takes it to the door.

Two parts make this an interview problem. The first is the availability read: for this address, which centers can deliver in time, and what do they have in stock? It runs on every screen the customer opens, so it must be fast. 'Can deliver in time' means travel time, not distance: a center two kilometers away across a river may be a 40-minute drive. The second is the order write: two customers can try to buy the last bottle of water at the same moment, and only one may get it. Every item in the cart must be held together, or none of them.

Keep the two apart in your answer. Reads use precomputed coverage and cached stock and may be a few seconds stale; the reservation goes to the database that owns the count and checks it in one transaction. The Grocery Delivery System topic covers a marketplace that guesses what is on a store's shelves; this topic is about stock the company owns and counts.

Questions to ask first

Whose stock? — Ours: about 3,000 centers, each with about 8,000 of a 40,000-item catalog
What is the promise? — Delivery within 60 minutes of ordering
Can one order come from two centers? — No: one center packs the whole order, one driver delivers it
How fresh must availability be? — A few seconds stale is fine; the order must never oversell
Volume? — 15 million shopping sessions and 3 million orders a day; evening peak 3× average
Where does the stock count come from? — The centers' warehouse management system (WMS) sends updates

What you will be able to do

Explain why a serviceable area is built from drive time and precomputed per area cell, not from a radius.
Serve availability in tens of milliseconds from coverage and a stock cache, and say how stale it may be.
Reserve every line of a cart at one center in one transaction, with conditional updates that cannot oversell.
Expire abandoned reservations safely, and reconcile the count with the warehouse system.
Choose the center for an order and hand it to dispatch.

Key concepts

Micro-fulfillment centers
Serviceable area
Travel-time isochrones
H3 cells
Availability cache
Conditional updates
Atomic reservation
Reservation expiry
Inventory sync
Shard by center

Functional requirements

Given an address, list the items that can be delivered there within 60 minutes
Show for each item whether it is in stock and how many can be ordered
Place an order with several items, all from one center
Hold the items while the customer pays; release them if the customer leaves
Assign the order to a center and a driver
Keep stock counts in step with each center's warehouse system

Non-functional requirements

Availability responds in under 100 ms at p99 (a target we chose)
Never sell more units than a center has: reservations are strongly consistent
Availability may lag the true count by a few seconds; checkout re-checks it
99.9% availability for browsing and ordering (a target we chose)
A failure in one region does not stop other regions

Interview questions

How do you decide which centers can deliver to a customer?
How do you make availability fast?
How do you guarantee you never oversell?
Why not just decrement a counter in Redis?
What happens to items a customer reserves but never buys?
How do you keep counts in step with the warehouse system?
How would you scale this to many cities?
How is the driver assigned?