The Problem
Costco Same Day Delivery is Costco’s grocery delivery service, powered by Instacart, that lets Costco members order eligible warehouse items online and receive them the same day, often within a selected delivery window. It includes groceries and fresh items, but prices are usually higher than in-warehouse prices because service and delivery fees are built in
Functional Requirements
- Customers can check which items are available for delivery to a specified location within one hour. The availability shown to the customer should combine inventory from all distribution centers capable of serving that address within the delivery window.
- Customers can place a single order containing multiple products and quantities.
Non-Functional Requirements
- Inventory availability queries should complete in under approximately 100 milliseconds. Low latency is important because these checks may sit on the critical path of product browsing and search-result rendering.
- Order placement must provide strong consistency. If only one physical unit remains, concurrent customers must not both be allowed to purchase it.
- The system should support inventory distributed across roughly 10,000 distribution centers, with a catalog of approximately 100,000 distinct products available across those locations.
- The ordering platform should also handle traffic on the order of 10 million completed orders per day.
Data Model
- Item: A catalog-level product that customers can browse or purchase, such as a specific size and flavor of Cheetos.
- Inventory: The stock of a particular item held at a specific distribution center. Inventory records are aggregated across nearby facilities to calculate how many units are available for a customer’s location.
- DistributionCenter: A physical facility where products are stored. Its location and service area determine whether its inventory can contribute to a customer’s one-hour delivery availability.
- Order: A collection of items and quantities reserved for a customer, together with the relevant delivery and billing information.
API Design
Next, we can translate the functional requirements into a small set of client-facing APIs. There are many additional fields and edge cases we could model here, but during an interview it is usually better to begin with the minimum contract needed to support the main user flows.
For this design, two endpoints are sufficient.
The first returns products that can be delivered to a customer’s location, optionally filtered by a search term. Because the result set may be large, the endpoint supports pagination so the client only receives a manageable number of records at a time.
GET /v1/availability ?latitude={LAT} &longitude={LONG} &keyword={KEYWORD} &page_size={SIZE} &page_number={PAGE} Response: { items: [ { item_id: ITEM_ID, name: NAME, quantity: QUANTITY } ] }
The second endpoint submits an order containing one or more products. The customer’s location is included so the system can validate that the requested quantities can be fulfilled by nearby distribution centers.
POST /v1/orders Body: { latitude: LAT, longitude: LONG, items: [ { item_id: ITEM_ID, quantity: QUANTITY } ] } Response: Order | Failure
The success response returns the newly created order. If the requested inventory is no longer available or cannot be fulfilled within the delivery area, the API returns a failure instead.
High-Level Design
1. Customers Can Check Product Availability by Location
We will begin with the first functional requirement: given a customer’s location, the system should return the products that can be delivered within one hour.
The request can be divided into two stages.
First, the system identifies the distribution centers capable of serving the customer within the required delivery window. Since every physical unit belongs to a distribution center, narrowing the search to nearby facilities prevents us from scanning inventory across the entire network.