This week in caching: Redis object cache, the parts that bite
For WP and app devs who added Redis and assumed it just works.
— alloptions is your silent memory hog — Till Krüss's notes on how a bloated wp_options autoload row gets cached as one giant key, evicted constantly, thrashing your hit rate.
— maxmemory-policy matters more than maxmemory — allkeys-lru vs noeviction is the difference between graceful degradation and write errors at capacity.
— persistent connections or you pay TCP every request — PhpRedis vs Predis: the C extension wins on high-traffic sites, measurably.
Bookmark: Till Krüss's Object Cache Pro docs — even the free reading explains group-flushing better than anywhere else.

This week in caching: Redis object cache for WordPress, honestly
For the WP crowd running a persistent object cache:
— Object cache vs page cache (they're not the same) — object cache memoizes DB queries inside a request and across requests; page cache stores whole HTML. You usually want both.
— The alloptions bomb — how a bloated wp_options autoload set turns Redis into a bottleneck, with the SQL to find your worst offenders.
— Redis Object Cache vs Object Cache Pro — what the paid fork actually buys you (relay, better serialization, analytics).
— Flushing safely on deploy — why wp cache flush mid-traffic can stampede your DB.
Credits to Till Krüss and the Pressidium engineering blog.
Bookmark: the alloptions audit query — gold for WP folks whose Redis looks busy for no reason.

This week in caching: the case for serving stale on purpose
Three reads that reframe "old" cache as a feature, not a bug.
— stale-while-revalidate, explained properly — Harry Roberts' walkthrough of Cache-Control: max-age=60, stale-while-revalidate=3600 shows how to serve the stale copy instantly while a background fetch refreshes it; the latency win is felt, not measured.
— stale-if-error as a free uptime layer — the RFC 5861 companion directive keeps your site up when origin 500s; gold for anyone running thin infra.
— Fastly's SWR support matrix — their docs clarify which CDNs honor it at the edge vs only in-browser (Chrome yes, Safari historically no).
Bookmark: Roberts' piece — the mental model of "correct now, fresh soon" sticks.

This week in caching: writing your first Varnish VCL without footguns

A starter default.vcl walkthrough. Skip if you're fully on a CDN edge.

— Strip tracking params in vcl_recv — normalize or remove utm_*, fbclid, gclid so one page doesn't fragment into 50 cache objects.
— Decide cookies deliberately — by default Varnish won't cache anything with a Set-Cookie or request Cookie; whitelist only your real session cookie, drop the rest in vcl_recv.
— Honor a bypass — pass through wp-admin, cart, and checkout paths explicitly; full-page caching a logged-in dashboard leaks data between users.
— Set a sane TTL with grace — set beresp.ttl = 1h; set beresp.grace = 6h; so a slow origin still serves stale-but-fast.
— Test with varnishlog — confirm hits show VCL_call HIT, not silent passes.

Credit to the Varnish Book authors for the grace-mode pattern.

Bookmark: the official Varnish 'Getting Started' VCL — the cleanest annotated baseline.

—
Соседний канал в сети: @affcareers_limassol

This week in caching: OPcache, beyond the defaults
Three reads that go past the copy-paste php.ini snippet everyone shares:
— Why opcache.revalidate_freq is the wrong knob — explains that on a deploy you want validate_timestamps=0 + an opcache_reset on release, not a 60s revalidate loop; clears up the most common stale-code bug.
— Sizing memory_consumption with opcache_get_status() — shows how to read cached_scripts vs max_cached_keys so you stop guessing at 128M; gold if you keep hitting OOM restarts.
— JIT is not a cache (and won't fix your TTFB) — sober take on why PHP 8 JIT helps CPU-bound math, not typical web request paths.
Credit to the PHP internals folks and Brent Roose's write-ups.
Bookmark: the opcache_get_status() walkthrough — one function call tells you if your config is actually sized right.

This week in caching: the stale-while-revalidate rabbit hole
Four pieces on serving slightly-old content so nobody waits on a cold cache:
— RFC 5861 in plain English — what stale-while-revalidate and stale-if-error actually promise, and which CDNs honor them.
— SWR at the edge vs in SWR (the React hook) — disambiguates the two things that share a name; skip if you already know the difference.
— Async revalidation gotchas — the thundering-herd problem when 10k users all trigger the background refresh at once, and request coalescing as the fix.
— Browser-side: Cache-Control with stale-while-revalidate — Chromium support notes for the response header version.
Credits: Harry Roberts and the Fastly docs team.
Bookmark: the request-coalescing piece — it's the part most SWR tutorials quietly skip.

This week in caching: stopping the stampede
What happens when a hot key expires and a thousand requests rebuild it at once. Roundup:
— Probabilistic early expiration (XFetch) — the Vargas algorithm that recomputes a value slightly before TTL based on how long the last build took; the cleanest math on dogpile prevention.
— Locking vs leasing — memcached's lease tokens compared to Redis SETNX locks, with the deadlock failure mode of naive locks.
— Why a tiny TTL jitter beats a fixed TTL — adding random seconds so 100k keys don't all expire on the same second.
Credits to the original RedisLabs and Facebook memcache papers.
Bookmark: the XFetch explainer — once you see the formula you can't unsee how many sites need it.