Ecom Cache Config

Per-index control over response caching for ecom search and recommendations traffic. Admins set TTLs on the index Configuration tab; ecom-worker translates those values into a standard Cache-Control request header on outbound Marqo calls; global-worker honours the header using its existing single cache layer.

End-to-end flow

The cache_config field lives on the index record in DynamoDB. The ecom_settings_exporter Lambda mirrors it into Cloudflare KV alongside the rest of the per-index settings. At request time, ecom-worker reads cache_config from KV and, for cacheable endpoints, attaches Cache-Control: max-age=N (or Cache-Control: no-store to bypass) to the outbound request to Marqo. Global-worker reads that header and uses it as the TTL for its single cache layer. When cache_config is absent or empty for an index, ecom-worker sends no header and global-worker falls back to its existing per-index KV-configured defaults — exactly the behaviour that shipped before this feature.

Seven endpoints are cacheable: search, composite_search, collections, get_documents, recommendations_similar, recommendations_complementary, and recommendations_queries. The agentic-search/* routes go through a different worker binding and are out of scope. Direct (non-ecom) Marqo customers are unaffected because their requests do not traverse ecom-worker. A 30-day ceiling is applied as a sanity bound on the max-age value before it leaves ecom-worker.

Admin UI

The Configuration tab has a Cache Config section with a Default TTL field and a per-endpoint table covering the seven cacheable endpoints. The section displays a yellow warning note about cache staleness: cached responses live until their TTL expires, so updates to product data, merchandising rules, or settings can take up to the configured TTL to be reflected on cached endpoints. Customers picking TTLs should weigh that lag against the latency and cost benefit of caching.