Design Real-Time Inventory & Availability

Start with why this is hard, because the difficulty is not where a newcomer expects it. If every grocery store handed Instacart a perfect, live list of exactly what was on each shelf, this would be a cache with a short expiry and nothing to interview on. That is not the world. A store's inventory system was built to run a register. The count it reports is hours stale, silent about the milk that just sold out, and confidently wrong about the item a manager moved to an endcap. The person who actually knows what is on the shelf is the shopper standing in the aisle. So availability is a belief you predict, correct as real people report what they find, and serve to a customer deciding whether to put a carton in their cart.

The arc of the design follows that reframe. Signals flow in from two sources that disagree, the retailer feed and the stream of shopper findings, and a prediction turns them into a probability that the item is really there. That score is read constantly, on every search and every product page, so serving it fast and consistently is half the problem. Sometimes the prediction is wrong: a shopper reaches for the item and it is gone. Then the system has to run a substitution conversation between customer and shopper before the order can complete. Three moving parts: predict the score, serve it two ways, and handle the miss.

The Instacart angle

The retailer's feed is the least trustworthy input in the whole system, so build around not believing it. A generic answer treats inventory as a number the store owns and you read. The Instacart answer starts from the fact that the number lies, and reaches for the source that does not: the community of shoppers physically scanning items off shelves all day. Instacart has written publicly that it predicts each item's availability as a probability rather than storing a boolean, and that shopper findings are the ground-truth signal that corrects the feed.