Quill

Services

The decision worth arguing about

The non-obvious decision is that Quill never issues a CloudFront invalidation, and understanding why explains the whole delivery design. CloudFront gives you 1,000 invalidation paths a month free and charges per path after that, but the real problem is not the price — it is that a publish in a CMS is not one path. Changing a shared component, a navigation entry or a legal footer invalidates thousands of rendered pages, and wildcard invalidations propagate across the edge on their own schedule, which means the editor who just fixed a typo sits watching a stale page and refreshing. So the delivery API is content-addressed instead: every publish creates an immutable content version, and every delivery URL carries that version, which lets us set a one-year max-age and never purge anything. What changes on publish is a single tiny pointer document naming the current version, served with a five-second TTL. A reader therefore pays one extra pointer fetch — usually already in the browser's cache or collapsed into the front end's build — and sees new content within about five seconds worldwide, with zero invalidation cost and no origin stampede, because the pointer is a few hundred bytes and the versioned content behind it was already warm from the preview traffic. The trade-off is real and we name it: storage grows with every published version rather than being overwritten, so a lifecycle policy expires versions older than the retention window, and rollback beyond that window means restoring from the database rather than flipping the pointer. For a content system where the ability to say exactly what was published on a given date is often a legal requirement, keeping the versions is a feature rather than a cost.

Services

The decision worth arguing about

Azure Front Door actually makes the tempting alternative more tempting, which is why the decision is worth restating here rather than copied across. Front Door supports cache purge by path and by wildcard at no per-path charge, so the cost argument against invalidation that applies on CloudFront does not apply on Azure. We still do not use it. Purge on Front Door is asynchronous and propagates across points of presence over a window measured in minutes, and it is rate-limited per profile, so a busy editorial day that publishes forty times an hour can queue purges behind each other. The immutable-version-plus-pointer design gives a consistent five-second worst case regardless of publish rate, and — the reason that matters more than the latency — it behaves identically on both clouds, so the delivery service has one code path rather than a CloudFront branch and a Front Door branch. Where Azure does change the shape is the URL rewriting. We keep the version out of the public URL using the Front Door rules engine to rewrite an incoming clean path into the versioned origin path, reading the current version from the pointer via a rules-engine condition. Front Door Standard caps the number of rules per rule set, and a deployment with many locales and many hostnames will reach that cap, at which point you either simplify the routing or move to Premium. We would rather flag that as a known ceiling than have a customer discover it when they add their ninth market. Asset derivative generation runs as a Container Apps job rather than in an edge function, because Azure has no Lambda@Edge equivalent with the same execution model; the derivative is generated once on first request, written to Blob Storage on an immutable key, and served from cache thereafter.