Skip to content

SYSTEM Cited by 2 sources

ZEOS Replenishment Recommender

ZEOS Replenishment Recommender is the inventory optimisation pipeline inside the ZEOS Inventory Optimisation System — the downstream consumer of the ZEOS Demand Forecaster's 12-week probabilistic forecasts. It produces replenishment-decision recommendations at per-SKU granularity and delivers them via two synchronous-agreement paths:

  1. Offline / batch — daily recommendation reports for all partners × articles, precomputed.
  2. Online / interactive — partner-portal-driven re-scoring of a subset of SKUs in response to ad-hoc inventory-setting changes.

Both paths use the same optimisation algorithm on the same feature vectors so online "what-if" answers and daily batch recommendations are guaranteed to agree. See patterns/online-plus-offline-feature-store-parity.

Optimisation algorithm

The optimiser minimises the 75th percentile of cost across Monte Carlo DES runs — see concepts/percentile-objective-optimisation — under an Extended (R, s, Q) policy with parameter vector θ = (t₀, Q₀, s, Q) plus lifecycle cutoff t_limit.

Per-sample evaluation:

  • Discrete Event Simulation — 12-week horizon; weekly ticks; intra-week ordered events (inbound/2 → fulfilment → inbound/2 → reorder check → cost accrual). Gamma-distributed replenishment lead times sampled per run. Returns lead times from empirical historical distributions. Counterfactual stockout demand — unfulfilled demand during stockouts sampled from the probabilistic forecast, not zeroed.

Per-sample cost — five pillars:

$$C(\theta; \omega) = C_{\text{holding}}(\theta) + C_{\text{inbound}}(\theta) + C_{\text{outbound}}(\theta) + C_{\text{returns}}(\theta) + C_{\text{lost sales}}(\theta)$$

  • C_holding — fees weekly on physical stock levels.
  • C_inbound — operational costs moving goods to the FCs.
  • C_outbound — operational costs moving goods from the FCs.
  • C_returns — processing fees for returned items.
  • C_lost sales — margin lost when demand is unmet, adjusted by return rate (a lost sale that would have been returned anyway isn't really lost margin).

Outer optimisation — risk-aware (not mean):

$$\theta^* = \arg\min_{\theta \in \Theta} Q_{0.75}!\left[ C(\theta; \omega) \right]$$

The 75th-percentile objective is Zalando's explicit choice: "This ensures our decisions protect against extreme, rare demand spikes." See patterns/probabilistic-forecast-plus-percentile-objective for the canonical composition pattern and patterns/des-plus-gradient-free-optimiser-under-uncertainty for the architectural pairing.

Outer search:

  • Gradient-free black-box optimiser searches θ-space. The specific family is not disclosed in either canonical source (both 2025-06 architecture post and 2026-01 paper announcement).

Empirical validation via computational backtest (Oct 2023–Sep 2024, ~2M articles × ~800 merchants, human-replenishment baseline): +22.11% GMV, +21.95% Gross Margin, +33.63% availability, +23.63% fill rate (theoretical 100%-adoption uplift). See concepts/ablation-study-forecast-vs-objective for the decomposition of which design choices contribute how much.

Pipeline shape

Feature generation

Same two-tier pattern as the forecaster — see concepts/data-preprocessing-vs-data-transformation-split:

Output: per-SKU feature vector containing:

  • Historical outbound data
  • Inventory states (current stock levels, stock in transit)
  • Inbound volumes
  • Pricing information
  • Article metadata
  • Cost factors
  • Return lead-time weights
  • 12-week probabilistic demand forecasts from the forecaster

Feature store

SageMaker Feature Store in both its modes — see concepts/online-vs-offline-feature-store:

  • Offline — S3-backed, append mode; cold storage use cases (batch pipelines, archiving, debugging); latency "in the order of minutes"; stores both daily datapoints and user-triggered feature-vector updates for long-term data retention.
  • Online — low-latency, low-throughput lookup of only the latest valid feature vector (either the daily-generated version or the most recent user-triggered update); 10–20 ms read/write per SKU; feeds both batch input generation and online serving.

The two-mode storage is explicit in the post:

"While offline feature store optimises for cost efficient high throughput data IO with latency in the order of minutes, online storage is optimised for low-latency, low throughput applications, providing lookup access to only the latest valid feature vectors."

Offline (batch) delivery

  1. Daily SageMaker Batch Transform runs the optimiser across all merchants + articles using the latest inventory setting from the offline feature store.
  2. Post-processing SageMaker Processing Job evaluates optimisation performance, enabling proactive model performance and drift monitoring.
  3. Recommendations stored in S3; a "report generated" notification is published to the respective event stream for downstream consumers.

This is a proactive cache of daily batch predictions — partners always see fresh recommendations without on-demand recomputation when their inputs haven't changed.

Online (interactive) delivery

When a partner changes inventory settings in the partner portal, the following async workflow fires:

  1. Enqueue on AWS SQS — each inventory-setting update becomes a queue message.
  2. AWS Lambda poller — Lambda drains the queue and serves each update request asynchronously.
  3. Feature fetch — for each inventory update, Lambda fetches the feature vector for the relevant SKUs from the online feature store.
  4. Multi-threaded optimisation — Lambda executes the optimisation algorithm with multi-threading parallelism (one thread per SKU or per independent sub-problem; exact parallelism model not disclosed).
  5. Store + notify — optimal predictions stored in S3; a notification is emitted to the backend event stream for the partner portal to surface fresh results.
  6. Side-effect: persist inventory-setting change to the offline feature store — so future offline batch predictions are consistent with the online what-if. This write is the load-bearing mechanism behind online+offline parity.

This is the canonical patterns/async-sqs-lambda-for-interactive-optimisation instance on the wiki.

Dual-mode delivery: the parity invariant

"It's important to note that the inventory optimisation algorithm and input features are synchronised between the two subsystems (online and offline), ensuring consistency across both engines."

The invariant is enforced by:

  • Single algorithm implementation — the same optimiser binary runs in both the Batch Transform job and the Lambda worker.
  • Shared feature-store namespace — both paths read the same feature vectors, and online writes back to the offline store.

Platform substrate

Canonical disclosure

Seen in

  • sources/2025-06-29-zalando-building-a-dynamic-inventory-optimisation-system-a-deep-dive — canonical platform disclosure. First wiki instance of dual-path optimisation serving where both paths agree by construction via a shared feature store + write-back.

  • sources/2026-01-14-zalando-paper-announcement-replenishment-optimization-extended-rsq — canonical algorithm disclosure. Nature Scientific Reports paper announcement names the specific policy class (Extended (R, s, Q) with Q₀ + t_limit extensions), simulator (DES, 12-week horizon, intra-week ordered events, Gamma lead times), objective (P75 not mean), counterfactual stockout-demand modelling, five-pillar cost decomposition, and quantile-LightGBM forecast source. Computational backtest: ~2M articles × ~800 merchants for 12 months shows +22.11% GMV / +21.95% Gross Margin / +33.63% availability / +23.63% fill rate vs human baseline. Baseline comparison shows Extended (R, s, Q) beats Tuned (s, S) / Periodic base-stock / Myopic Newsvendor by +8.72pp / +9.61pp / +17.04pp GMV respectively under identical data + simulation settings. Ablation study decomposes forecast × objective contribution: probabilistic forecast is the first-order lever (+15.74pp), percentile objective is the second-order stability layer (+3.09pp).

Last updated · 542 distilled / 1,571 read