Skip to content

CONCEPT Cited by 1 source

Discrete Event Simulation

Definition

Discrete Event Simulation (DES) models a stochastic system as a sequence of discrete events at discrete time steps, where at each step the system state evolves deterministically given sampled random inputs. Unlike continuous-time simulation (integrating ODEs) or purely analytic models (closed-form expectations), DES:

  • Advances time in fixed discrete ticks (e.g. one week per tick).
  • At each tick, executes a deterministic ordered sequence of state transitions (inbound → fulfilment → replenishment decision → cost accounting).
  • Samples stochastic inputs (demand, lead times, returns) from their distributions at the tick boundary.
  • Accumulates summary metrics (cost, service level) across ticks.

One DES run = one "alternate timeline"; Monte Carlo over many runs averages across plausible futures.

Why DES for inventory

Classical inventory theory uses closed-form expectations (Newsvendor, (s, S) steady-state). These break down when:

  • Multiple stochastic inputs interact — demand + lead times + returns jointly determine inventory position.
  • Branching logic matters — stockouts truncate fulfilment; replenishment decisions depend on inventory position at the moment of the review.
  • Policy parameters are non-trivial — an Extended (R, s, Q) policy with kick-start and lifecycle-cutoff has too many parameters for analytic closed-form evaluation.

DES sidesteps the closed-form problem: simulate the system forward, count the costs.

Canonical shape (from Zalando ZEOS)

The paper announcement specifies the intra-week event ordering explicitly:

  1. Intra-week processing — expected inbounds and returns are added half before and half after demand fulfilment. This half-before / half-after split is the DES's approximation of a continuous-flow arrival process using a single discrete tick. (Approximates the fact that goods don't all arrive at 00:00 Monday.)
  2. Demand realisation — sample weekly demand from the probabilistic forecast; fulfil from on-hand inventory. If demand > on-hand, record a stockout (with the counterfactual demand captured for cost calculation).
  3. Replenishment decision — at review points, check inventory against reorder point s. If breached, place an order of size Q that enters transit with a Gamma-distributed lead time sample.
  4. Cost accumulation — accrue holding, inbound, outbound, returns, and lost-sales costs for the week.

Horizon: 12 weeks per run. Many runs ("thousands of plausible futures for each candidate policy") are aggregated to compute the cost distribution scored by the P75 objective.

Verbatim

"How do we 'test' a policy before it hits production? We run a Discrete Event Simulation (DES) over a 12-week horizon. Each Monte Carlo run represents one 'alternate timeline' where demand, returns, and lead times evolve stochastically."

Why the event ordering matters

DES output is sensitive to when stochastic variables are sampled and when state transitions fire. Ordering choices the paper makes explicit:

  • Inbounds + returns around demand fulfilment — half-before / half-after ensures that same-week arrivals can partially satisfy same-week demand. Pure "end-of-week inbound" would underestimate fulfilment rate; pure "start-of-week inbound" would overestimate it.
  • Replenishment decision after demand realisation — the reorder check sees the post-fulfilment inventory level. Pre-fulfilment check would trigger on the expected post-fulfilment level, which is a different policy.
  • Cost accrual at end of week — holding cost is charged on the average (or end-of-period) stock level, not the maximum.

DES vs pure Monte Carlo

DES and Monte Carlo are composed, not alternatives:

  • Monte Carlo — the outer loop that averages outcomes across sampled realisations.
  • DES — the inner mechanism that, given one set of samples, computes what would have happened step-by-step.

The composition: for each candidate policy θ, run N DES simulations (each a Monte Carlo sample), aggregate costs via percentile, hand to the gradient-free optimiser. See concepts/monte-carlo-simulation-under-uncertainty for the outer loop.

Tradeoffs

  • Compute cost. Each DES run is O(horizon × events-per-week); per article × merchant with N Monte Carlo samples × optimiser iterations, the total compute grows fast. Zalando amortises this by batching in the daily SageMaker Batch Transform + the online Lambda path.
  • Event-ordering choices are non-obvious. Reasonable people can disagree on whether to model inbound as beginning-of-week, end-of-week, or distributed — and the choice materially changes fulfilment rates in the simulation. Zalando's half-before / half-after is a sensible split, but it's a modelling choice, not a mechanical consequence.
  • 12-week horizon is a fashion-commerce-specific choice. Shorter horizons miss seasonal + decay-phase effects; longer horizons compound uncertainty and demand more compute.

Canonical instance (Zalando ZEOS)

Seen in

Last updated · 428 distilled / 1,221 read