A quick-commerce platform's architecture is bounded by things that are not software: store leases, courier supply, road conditions, and the physical time to pick items off a shelf. How should such constraints enter the design?

Why these are architectural, not operational

A ten-minute promise decomposes into pick time, pack time, dispatch wait and ride time. Software controls perhaps a third of that budget. If picking takes four minutes and the ride takes five, then no amount of API optimisation creates the promise; the architecture must instead be shaped so that the software portion is small and predictable, and so that the physical portion is measured, forecast and acted on.

That has direct structural consequences:

• The catalogue a customer sees must be store-scoped, because the constraint is not "is this product in the business" but "is it on a shelf 1.8km away right now."
• The ETA must be a model, not a constant, fed by live rider supply, current queue depth at the store, and historic pick times for the basket composition — and it must degrade to a conservative constant when its inputs are stale.
• Demand forecasting becomes part of the serving architecture, because stock placement decisions made hours earlier determine whether the promise can be met at all.

The failure mode that defines the domain

The physical world does not roll back. A rider dispatched is a cost incurred. An item picked is stock committed. Compensation is not a database operation; it is a refund, a return, or a wasted trip. This is what makes the domain unlike a purely digital marketplace, and it argues for strong consistency at the point of commitment — the reservation against a specific store's stock — while allowing nearly everything else to be eventually consistent.

The judgement

The mature version of this design does not try to eliminate physical uncertainty. It quantifies it and prices it into the promise: a slightly longer committed ETA that is met 99% of the time is a better product and a far cheaper system than an aggressive ETA met 80% of the time with a compensation workflow behind it.