Case Study: The Two-Minute Promise

The situation. A national nonprofit’s platform serves millions of page views a month — local chapter pages, events, mentors, resources — and needs to feel instant everywhere in the country. The standard answer is caching, aggressively, at every layer. But this isn’t a brochure site: hundreds of chapter volunteers edit content daily, events flow in continuously from Salesforce, and a presenter change made the night before a webinar has to be live — not “live within a few hours when the caches roll over.” Speed and freshness pull in opposite directions, and most sites quietly pick one. We were asked for both.

The architecture. A page on this platform is cached four times between the visitor and the database: in the visitor’s browser, at Cloudflare’s global edge, in each delivery server’s OpenLiteSpeed page cache, and beneath all of it a Redis object cache per server holding the assembled data that makes fresh page-builds fast. Cached pages serve in milliseconds; when a page’s time expires, the server hands out the just-expired copy while a single background request quietly rebuilds it — so visitors never wait on a rebuild, and a popular page expiring never triggers a stampede of servers all rebuilding it at once.

The hard part is the multiplication. With multiple delivery servers, “clear the cache” isn’t one operation — it’s a choreography: the same URL cached independently on every server plus the edge, and the order matters (clear the edge before the origin and the edge just re-inherits the stale copy). Editors saving pages, nightly CRM syncs touching hundreds of events, and sponsors whose logos appear across dozens of pages all generate invalidation work at once. Done naively, that’s either stale content or a self-inflicted traffic storm — a fleet forced to rebuild thousands of pages simultaneously is indistinguishable from being attacked.

What we built. A coordinated invalidation pipeline that treats cache clearing as seriously as serving:

• A durable queue with priorities — an editor’s save outranks background maintenance, always, so human changes never wait behind housekeeping
• Verified purges — a purge isn’t “done” when an API says OK; the system re-requests the page and confirms a fresh copy is actually being served, on every layer, before the job closes
• Storm-proofing — fleet-wide concurrency caps spread heavy invalidation over time so a big sync can never stampede the origin; a kill switch and live backlog monitoring stand behind it
• Scope discipline — each edit purges exactly the URLs it affects (and knows which taxonomy pages don’t exist and never need purging), so the caches that should stay warm, stay warm
• Runtime tuning with an audit trail — throughput knobs adjustable from the ops console, every change with a required reason and history, calibrated against 30 days of real queue telemetry

Results.

• Cached pages serve in milliseconds; the platform absorbs ~120 million requests a month with a four-server delivery fleet
• A chapter volunteer’s edit — or a Salesforce change — is live for visitors in about two minutes, a number leadership can promise out loud
• Content syncs touching hundreds of events drain through the queue without a visitor ever feeling it
• Cache expiry is invisible: no visitor ever waits on a page rebuild
• And the operators can see all of it — queue depth, lane counts, verification results — so “is the cache fresh?” is a dashboard answer, not a debugging session