Databricks has published a detailed architecture for fashion retailers building personalised product recommendations, combining batch-generated suggestions with a separate real-time path for shoppers’ current activity. The practical idea is to keep routine recommendations quick while letting a shopper’s immediate browsing shape what appears next.
Databricks Watch analysis
What happened
In a 2 October article, Databricks describes a recommendation system built for an unnamed fashion e-commerce platform in Asia, which it says serves more than one million monthly active users and has a catalogue of over 100,000 products. The company says the system ingests about 1,000 events per second, including searches, product views and purchases.
The architecture has two serving paths. For familiar surfaces such as home-page carousels and category rankings, a nightly job generates ranked product lists and stores them in Lakebase for quick lookup. For session-aware recommendations, the article says the shopper’s current activity goes directly in the request to a Model Serving endpoint, rather than waiting to be ingested into the lakehouse.
Databricks also describes using AI Search to retrieve candidate products, Lakebase for online feature serving, and Model Serving for inference. The Databricks architecture article sets out the company’s reference design and account of the implementation.
Why it matters
The split makes a useful trade-off visible: nightly recommendations can serve predictable placements from a prepared list, while a real-time path can respond to what a shopper is doing now. The article also gives teams concrete components and data flows to consider, rather than treating “real time” as a magic adjective with a cloud bill attached.
Our read
This is a useful blueprint for data and machine-learning teams weighing a unified platform against a collection of separate services. The most actionable detail is the distinction between precomputed recommendations and live session scoring. The performance and business outcomes remain Databricks’ account of its system, so teams should test the design against their own traffic, freshness needs and costs before taking the architecture as a ready-made recipe.
What to watch
- Whether the remaining architecture details clarify the real-time path’s latency and operational requirements.
- How the nightly refresh cadence performs when inventory or shopper behaviour changes quickly.
- Whether Databricks or the retailer publishes measured recommendation quality or business results.
Discussion spark: For retail recommendations, would you prioritise fast, predictable results from nightly precomputation, or invest in real-time scoring that can respond to each shopper’s current session?
Sources and evidence
not affiliated with or endorsed by Databricks