A checkout service publishes an OrderPlaced event that an inventory service consumes asynchronously to decrement stock. Immediately after checkout, the customer refreshes the product page and still sees the item as 'in stock' with the same quantity as before their purchase. What's happening, and what design choices reduce how often customers see this?

## What the customer is actually seeing What the customer is observing is the **eventual-consistency window** that's a direct, unavoidable consequence of decoupling checkout from inventory via an asynchronous event rather than a synchronous call. To see why, walk through the actual sequence of steps. - **First**, checkout completes its own transaction — payment is authorized, an order row is written — and, as part of or right after that transaction, it publishes an `OrderPlaced` event to a broker or outbox. Checkout's job ends there; it does not wait for inventory to react. - **Second**, the inventory service has its own consumer process, running independently, that polls or receives events from that topic/queue and, on receipt, updates its own stock count and read model. The time between step one and step two — call it the **propagation lag** — is where the product page can show a wrong (stale) quantity, because the product page reads from inventory's read model, which hasn't been told yet. ## Why the gap is there by design This gap exists by design, not by accident: the point of using an event instead of a synchronous "decrement stock" call from checkout is that checkout's success no longer depends on inventory being fast or even up. If inventory's database is under heavy load or its service is redeploying, checkout still succeeds instantly for the customer, and the stock decrement simply catches up a moment later. The alternative — checkout synchronously calling inventory and waiting for the decrement before returning success — would eliminate the staleness window entirely, at the cost of coupling checkout's availability and latency to inventory's health, usually the worse trade for a customer-facing purchase flow. ## When the window stops being harmless Under normal, healthy conditions this window is typically tens to low hundreds of milliseconds — negligible for almost any real user. It becomes a real problem in two situations: - Sustained high load causes **consumer lag** to grow into seconds or minutes, so many customers hit the stale window. - The inventory consumer is down/erroring, so the window becomes unbounded until someone notices. The concrete production signal is consumer lag — most brokers expose how far behind a consumer group is from the head of the stream — and a mature system alerts on lag crossing a threshold well before customers start noticing wrong quantities. ## Techniques that shrink the visible window A few concrete techniques shrink the visible window in production. - **First**, keep the hot path narrow and fast: the inventory consumer should do the minimum work needed to update the count, deferring slower side effects like analytics or supplier notifications to further downstream events, so the count itself catches up quickly. - **Second**, some systems perform an optimistic, synchronous reservation at checkout time — checkout itself calls a lightweight, fast inventory-reservation check to decrement a reserved-quantity counter before publishing `OrderPlaced`, so the "available to sell" number updates immediately while fuller inventory bookkeeping still happens asynchronously via the event. This is a deliberate **hybrid**: sync for the number that must be correct fast, async for everything else. - **Third**, for the product page itself, some teams just accept the staleness for a read that isn't safety-critical, since the authoritative check that actually prevents overselling happens at the moment of the next purchase attempt, not at the moment of a page read. ## The dangerous version: overselling The dangerous version of this problem isn't a customer seeing a stale count for a second — it's two customers each seeing "in stock" and both completing checkout for the last unit because the reservation step wasn't synchronous or fast enough, resulting in an oversold item that has to be canceled and refunded after the fact. This is why the reservation/decrement itself is often kept on a fast, low-latency path even if not fully synchronous end-to-end, while the rest of the inventory pipeline — supplier notifications, analytics, warehouse routing — stays fully asynchronous, because those don't need to be correct within milliseconds, only eventually. ## How large retailers split it This exact pattern shows up at large e-commerce retailers: the checkout flow performs a fast, synchronous stock check and reservation against a dedicated, low-latency inventory-reservation service, while the broader "update the warehouse management system, notify suppliers, refresh analytics dashboards" fan-out happens via OrderPlaced-style events consumed by several independent downstream services, each catching up on its own schedule without checkout ever waiting on them.