Design Grocery Delivery Platform

Problem Statement: On-Demand Grocery Fulfillment

An on-demand grocery delivery platform is an Instacart-style three-sided marketplace connecting customers, partner retail stores, and gig shoppers, with a sub-hour delivery promise. The three sides each have different needs and the platform mediates all of them: customers want a delivery window honored, stores want their inventory sold without overselling, and shoppers want efficient batches that maximize their earnings.

What makes grocery harder than general e-commerce is the product itself. The inventory is perishable and the platform does not own it — partner stores expose available-to-promise (ATP) feeds, and that store-level ATP must be authoritative before checkout or you sell items that are not on the shelf. Items have substitution and weight variance: a customer orders bananas, the exact ones are out (substitute), and they are priced by weight (the final charge depends on what the shopper actually weighs). And the delivery window is the product — not the checkout speed, but the on-time delivery in the committed window is what the customer is buying.

The scale anchors: ~20M monthly actives, ~2M orders/day, ~5k partner stores, ~100k active shoppers, with catalog reads at p99 ≤200ms, checkout at p99 ≤450ms, and a target of 94% on-time delivery in the committed window. The headline metric is delivery on-time-ness, not request latency — the system's job is to honor a physical-world promise.

The failure that defines the design: a customer adds the last carton of eggs to their cart, but the store's ATP feed is 5 minutes stale, so a second customer also adds it and both check out — an oversell that ends with one customer's order short an item, a refund, and lost trust. Store-level ATP correctness with reservation-on-add is the spine of the whole system, because in grocery the inventory is real, finite, perishable, and not yours.