Translating a product catalog with an LLM is not a translation problem. It is a cache invalidation problem.
The model call is the cheap part. The hard part starts the moment the source catalog moves, and retail catalogs move constantly. A title gets a new size suffix, a supplier rewrites a description, an attribute appears that was never there before. Now you have to decide which of your translated fields are stale and which are still fine.
Re-translate everything on every sync and your cost and latency scale with the size of the catalog instead of the size of the change. Re-translate nothing and the storefront quietly drifts away from the source until someone finds it in a support ticket.
What works for me: store each translation keyed on a hash of the exact source fields that fed the prompt, plus the prompt version and the target locale. Change any of those and the entry is invalid. Change none of them and you serve what you already have. The model becomes a fill-on-miss function behind a cache rather than a stage in the pipeline.
The useful side effect is that prompt changes become reviewable. A new prompt version is just a new key, so you can roll it through a slice of the catalog instead of rewriting the whole store in one job.
If you run LLM pipelines over data that keeps changing: what do you key on, and where does that key first betray you?