Most inventory problems at scale trace back to one architectural decision: whether availability is recomputed on a schedule or maintained by the movements themselves. The first approach, often called leveling, is what most systems do. The second, event-based processing, is what a modern order operations layer does. The difference is worth understanding in detail, because it explains both why leveling oversells and why event-based does not.
Leveling, and the Race Condition It Creates
Leveling recalculates available inventory periodically. A job runs on an interval, reads the current on-hand and the accumulated sales since the last run, computes availability, and publishes the result to each channel. Between runs, every channel holds the last published value.
The problem is a classic race condition. Two channels can both read the same available number, both accept an order against it, and neither knows about the other until the next leveling run reconciles them. The system is not tracking a single authoritative count in real time; it is distributing periodic snapshots and hoping no two orders land against the same snapshot before it refreshes. At low order rates the collision probability is low. As the arrival rate of orders climbs relative to the leveling interval, collisions become statistically inevitable. Shortening the interval lowers the probability but never reaches zero, because any nonzero window admits the race.
Event-Based Processing, and How It Closes the Window
Event-based inventory treats each movement as a discrete event applied to a single authoritative count. A sale, a return, a receipt, a cancellation, and a transfer are all events, and each one updates the available quantity as it is processed rather than waiting for a scheduled recomputation. Channels read from, and are published the result of, that continuously maintained count.
The reason this removes the race is that there is no snapshot to collide against. The available number reflects the events applied so far, and each new order is evaluated against the current state rather than a periodic copy of it. In practice a well-built layer processes these events continuously and reconciles the published picture across channels within minutes, so the number every channel sees stays close to the authoritative count rather than drifting until the next job runs. Overselling stops being a structural output because the structural gap, the interval, no longer exists.
Reconciliation Still Matters
Event-based does not mean fire-and-forget. Systems still need a reconciliation path, both because upstream sources of truth (a warehouse system, an ERP, a 3PL feed) update on their own cadences and because events can arrive out of order or be delayed by a downstream outage. The right pattern is event processing for the live picture plus periodic full reconciliation against the systems of record to correct any drift. When a downstream system is unavailable, events queue and process on recovery rather than being lost, so the count converges to correct once connectivity returns. The goal is a live count that is accurate within minutes and a reconciliation process that guarantees it does not diverge from the authoritative sources over time.
Why This Is Hard to Retrofit
Converting a leveling system to event-based is rarely a configuration change, because the assumption of periodic recomputation is usually baked into the data model and the integration layer. This is why the practical path for most enterprises is to maintain the event-based picture in an order operations layer that sits alongside existing systems, ingesting movements as events and publishing an accurate count to each channel, rather than re-architecting every underlying system to be event-native.
For the business case behind this architecture, see the deep-dive on real-time versus batch inventory.
Frequently Asked Questions
Leveling recomputes availability on a schedule and publishes snapshots to channels between runs. Event-based processing updates a single authoritative count as each movement occurs. Leveling leaves a window where channels act on stale snapshots; event-based removes that window.
Because two channels can accept orders against the same snapshot before the next leveling run reconciles them. It is a race condition. Shortening the interval reduces the odds of a collision but never eliminates it, since any nonzero window admits the race.
The practical target is an accurate picture across every channel and location within minutes, maintained continuously. The point is not a specific millisecond figure but that the count is kept current by events rather than rebuilt on a fixed interval.
Yes. Event processing maintains the live count, and periodic full reconciliation against the systems of record corrects any drift from delayed or out-of-order events and from upstream sources updating on their own cadence. The two work together.
Usually not through configuration, because leveling is typically baked into the data model and integrations. The common path is to maintain the event-based picture in an order operations layer that runs alongside existing systems rather than re-architecting each one.
