Feature Store · View 01 of 21 · Context and scope
Decisions
- The platform reads every source and writes to none of them. A feature store that writes back becomes a second system of record for data it does not own.
- Model training, model serving and the model registry sit outside the boundary. The platform serves them; making it host them would couple a data contract to a deployment cadence.
- Five consumer surfaces, one of which is a batch consumer with entirely different latency needs — which is why there are two access paths rather than one.
Assumptions
- 40M monthly active users, 1.1M partner stores, 180k couriers, 2.2M orders/day peaking at 4,500/minute.
- 45 models in production owned by 9 teams; 1,400 features in 120 groups over 6 entity types.
- Courier telemetry peaks at 1.4M events/second into materialisation.
Risks
- A source team changes an event schema without notice; the platform's only defence is the contract guard, which stops a bad batch but cannot restore a missed window.
- The weather and traffic feed is a third party with no SLA to the platform; features derived from it are the ones most likely to be stale at peak.