Updates stopped costing you speed

The problem

DevMeme keeps the whole public site in a shared cache so pages come back immediately. That works right up until an update ships, at which point the cache belongs to the old version and every request has to be rendered from scratch again.

Repository measurements taken on 2026-07-19 put the warm path at 728 requests per second and the cold render ceiling at roughly 37. These are dated engineering measurements rather than a service-level promise, but the shape is the point: the gap between warm and cold is about twenty to one. An update used to drop the site into the slow side of that gap.

What changed

The site runs as a cluster. Four web workers share the load, with a separate process for scheduled jobs. One worker restarting is no longer the whole site restarting.

Each build gets its own cache generation. The new version is built next to the running one and fills its own cache. Nothing is shared with the old generation, so a half-finished deploy cannot serve you a page built from two different versions.

The cache is filled before the switch, not after. The deploy warms the entire public corpus and refuses to go live if too few pages verify as cached. The new version becomes active already warm.

Deploys got harder to get wrong. A deploy now ships the exact pushed commit rather than whatever happens to be sitting on the server, and refuses to redeploy a commit that is already live.

What you should notice

Ideally nothing at all. No maintenance window, no stretch of sluggish pages after an update, no half-updated page. The changes on this site’s changelog land without the site feeling different while they do.