The engineering bottleneck with assembled stacks
Growth teams typically rent recommendations or build them in a different system from the catalogue, then fight the seam forever: new products appear in search tomorrow and in recommendations next week, deleted items keep being recommended, and the behaviour data that would improve ranking sits in an analytics tool the API cannot read.
Architecture on the Software Lifecycle Cloud
Storefront and app functions write events into a behaviour table keyed by user and time; catalogue rows carry the descriptive fields a vector index embeds. The recommendation function reads the user’s recent items, asks the index for neighbours, filters against live catalogue rows — stock, region, permissions — and returns ranked ids with the reason recorded to a results table for later evaluation.
Freshness is the feature
Because the index derives from the catalogue table, a product added this morning is recommendable this morning, and a discontinued product leaves the candidate pool when its row does. Most recommendation quality problems in the wild are freshness problems wearing a machine-learning costume; the boring architecture of one source of truth quietly removes them.
- Behaviour events never leave the project, so ranking experiments read the same data the API writes
- Filtering (stock, territory, age gates) happens against live table rows after retrieval, never against stale copies
- Returned rankings are logged, so “did recommendations improve conversion” is answerable from project data
Start with similarity, earn the complexity
Item-to-item similarity over catalogue embeddings covers a surprising share of what products need: more like this, because you viewed, pairs well with. Behaviour-trained ranking can come later, trained on the event table this project has been accumulating since day one — the data asset compounds either way, inside your zone.
Frequently asked questions
Not to start. Vector similarity over catalogue content plus the user’s recent behaviour covers classic recommendation surfaces. If you later train a ranker, the event table in the same project is its training set — no export agreement with an analytics vendor required.
Immediately: the index is declared over the catalogue table, so a new row is embedded and becomes a candidate without a sync job. The same applies in reverse when a product is discontinued.
Yes. The function can assign variants by user key and log which ranking each user saw alongside the outcome events. That is ordinary table design in the project, not a separate experimentation platform.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.