Short write‑ups of problems we hit running a real commerce operation and what we changed in the code because of them. No product announcements; just the reasoning.
After a flush, the first visitor to each storefront page pays for the render. We have written the thing that pre‑pays three times: a link‑following crawler from a package, a two‑pass seeder‑then‑deep crawl with concurrency rules, and — the one we kept — a list of the pages people actually visit, fetched in order of traffic, at a concurrency that can never outbid a live shopper. Why each version was wrong for the next stage, and the surge‑protection bug that made the warmer most aggressive exactly when it should have been gentlest.
Every storefront page sends one small request to our own endpoint — not to a third party. From it: visitors, sessions, page views, country, device, referrer, the traffic source that becomes attribution, registration and add‑to‑basket conversions, "who is on the site right now", product interest per customer, and the list of most‑visited pages that decides what the cache warmer warms. Why a beacon that fires on cached pages was the only design that could work, how bots are filtered, and what we deliberately do not collect.
Every deploy was emptying the storefront cache and restarting server-side rendering, even when nothing on the front end had changed. The cause was one string baked into one JavaScript chunk. The fix was a checksum and a meta tag.
Our storefronts are server-rendered and personalised, which is the worst case for an HTTP cache. Here is how we put Varnish in front of them anyway — two hash buckets, a logged-in bit, tagged objects, surgical bans, and a warmer that only warms what people actually visit.