Stale Category Page After Catalog Import
A merchant runs a nightly catalog import that updates 40,000 products across 300 categories via the REST API. Category and product pages are served through the full-page cache with a 24-hour TTL, and Varnish sits in front. After the import, merchandisers report that category listing pages still show old prices for up to a day, while product detail pages update correctly within minutes. The catalog uses the default cache configuration with no custom cache tags. Redis is configured for both the default and page cache backends. The import completes in 35 minutes and writes products one at a time through the product repository.
1. Diagnose why category pages go stale while product pages refresh, and explain the cache-tag mechanism involved.
Read the worked answer
Category listing pages aggregate many products, so their cache identity must depend on tags for every product and category they render. The full-page cache stores each page under an FPC identifier plus the tags emitted during rendering. When a product is saved through the repository, Magento cleans entities whose tags intersect the product's tags (e.g. cat_p_123).
Product detail pages carry the saved product's tag, so they are purged. Category pages are only purged if they were rendered with the affected product tags. If the listing is cached under category-level tags only (or the product cache context is missing), a product save does not invalidate the category page. The 24h TTL then governs staleness. The fix is to ensure the listing block adds product tags for every product in the collection, not just the category tag, so the save triggers invalidation of each dependent listing.
2. The team proposes lowering the TTL to 5 minutes to mask the problem. Evaluate this and propose a better approach.
Read the worked answer
Lowering the TTL to 5 minutes trades correctness for load: with 300 categories and heavy traffic, every cache miss hits PHP, Redis, and the database, and during the 35-minute import the churn multiplies. It also does not fix correctness - a page can still be stale for 5 minutes, and it hides the real defect (missing tags).
Better approach: (1) confirm the listing block emits tags for all rendered products; (2) verify the import uses the product repository so save-time invalidation fires (direct DB writes bypass it); (3) if bulk performance matters, batch saves and rely on tag-based invalidation rather than TTL; (4) optionally warm the cache for hot categories after import. Keep a generous TTL and depend on tag invalidation for freshness.