PATTERN Cited by 1 source
Online + offline feature store parity¶
Problem¶
ML systems that serve both batch predictions (cheap, high-throughput) and online what-if predictions (interactive, low-latency) need a dual-mode feature store: one tier for cheap bulk scans, one tier for fast lookups. But the moment you have two stores, you have a consistency problem:
- Yesterday's batch saw feature vector
v1. - The user just adjusted an inventory setting; the online
system runs against
v2. - Next daily batch reads...
v1?v2? which is authoritative?
If the two stores drift, partners lose trust in the tool — their interactive "what-if" numbers disagree with the batch report.
Pattern¶
Enforce a parity invariant: same algorithm, same feature vectors, synchronous write-back from online path to offline store.
- Single algorithm implementation — the batch path and the online path invoke the same optimisation / inference logic. No forked code paths.
- Online reads from online store, offline reads from offline store — normal.
- Online writes go to both stores — any user-triggered feature-vector update is written (a) to the online store so the next online request sees it, and (b) to the offline store (in append mode) so the next daily batch sees it too.
- Offline store history is complete — daily datapoints plus user-triggered updates are both persisted; an auditor can reconstruct any state at any time.
Invariant¶
"The inventory optimisation algorithm and input features are synchronised between the two subsystems (online and offline), ensuring consistency across both engines."
This is stated at architectural level, not as an afterthought.
Canonical instance (Zalando ZEOS)¶
Zalando ZEOS's replenishment recommender implements the pattern with SageMaker Feature Store:
- Online store: 10–20 ms read/write per SKU; serves the partner-portal interactive path.
- Offline store: S3-backed, append mode; serves the daily SageMaker Batch Transform path.
- Write-back on online update:
"Lastly, in addition to serving the online request, we also persist the inventory setting update to the offline feature store, making future offline predictions consistent."
The pattern is closed via the same optimiser implementation running in both Lambda (online) and SageMaker Batch Transform (offline).
Seen in¶
Related¶
- concepts/online-vs-offline-feature-store — the concept this pattern keeps safe.
- systems/aws-sagemaker-feature-store
- systems/zeos-replenishment-recommender
- patterns/async-sqs-lambda-for-interactive-optimisation — sibling pattern on the online write path.
- companies/zalando