Grocery Delivery System

Instacart-style marketplace

Design a service where customers order groceries from local stores, shoppers pick the items off real shelves, and orders arrive in a chosen delivery window, even though the platform never knows exactly what is on those shelves.

Overview

A grocery delivery marketplace sits on top of stores it does not own. A customer picks a store, fills a cart and chooses a delivery window; a shopper goes to the store, picks the items off the shelves, handles anything that is missing, and delivers. Unlike a warehouse retailer, the platform never has an exact count of what is on the shelf, and unlike food delivery, an order can hold 40 items and take an hour to pick.

That shapes three problems an interviewer will push on.

Availability. Retailers send stock updates rarely (Instacart's 2018 post says typically once a day), but shelves empty within hours. The platform predicts the chance that each item can be found, and uses what shoppers scan and fail to find as live signals.
Capacity. A delivery window is a promise. Offering too many windows makes deliveries late; too few loses orders and leaves shoppers idle.
Money. The final total is unknown at checkout: produce is weighed, items are replaced or missing. The design must charge exactly once, for what was delivered.

The company examples here come from Instacart's own engineering blog; the rest is a generic design.

Questions to ask first

How many orders and stores? — 1 million orders a day from 20,000 partner stores, about 40 items each
Delivery promise? — Two-hour windows, same day or later; some areas offer faster delivery
Who shops? — Shoppers who pick and deliver (full service); busy stores may split picking and driving
Stock data from stores? — A daily feed per store, plus signals from shoppers during the day
What if an item is missing? — Replace it by the customer's preference, or refund it
Weighed items? — Priced per pound; the final price is known only after weighing

What you will be able to do

Explain why availability is a prediction, and how shopper scans feed it.
Estimate delivery-window capacity and book a window without overbooking.
Describe how orders are batched and routed as a vehicle routing problem with time windows.
Design the picking flow with replacements and weighed items, working offline.
Authorize with a buffer and capture the exact final amount.

Key concepts

Availability prediction
Found and not-found signals
Delivery window capacity
Atomic slot booking
Order batching
Vehicle routing with time windows
Replacements
Weighed items
Authorize, then capture less

Functional requirements

Browse a store's catalog, with items likely to be missing marked or hidden
Choose a delivery window that still has capacity; see its fee
Place an order with a replacement preference per item
Shoppers receive trips, pick items by scanning them, weigh produce, and mark items not found
Customers approve or reject replacements during picking, and track the order to the door
Charge the final amount for what was delivered, with an itemized receipt

Non-functional requirements

A window is never booked past its capacity
At least 95% of orders arrive inside their window (a target we chose)
The shopper app keeps working through poor in-store connectivity and syncs when back online
A customer is charged once, and never more than they authorized without asking
Availability shown to customers reflects shopper signals within minutes (a target we chose)

Interview questions

How do you know if an item is in stock when you do not own the store?
How do you decide how many orders a delivery window can take?
How are orders assigned to shoppers?
How do you charge correctly when the final price is unknown at checkout?
What happens when an item is missing?
How does the shopper app work with bad connectivity?
How would you scale this to many cities?