Compute and delivery for news publishers
Publishing has a traffic profile that no amount of capacity planning predicts: a story breaks, an aggregator picks it up, and one article receives more traffic in twenty minutes than the site normally sees in a day. You cannot schedule it, and you cannot afford to run a fleet sized for it permanently.
The number that decides whether you survive a spike
Almost all of the defence is in the cache hit ratio, and the leverage is at the top of the table rather than the bottom. Going from 90% to 99% cuts origin load by a factor of ten, which is generally a configuration problem; obtaining the same result by scaling the origin ten-fold is a procurement problem and will not complete in the twenty minutes you have.
Which means the work worth doing is whatever stops pages being uncacheable. The usual culprits are a session cookie set on every response, a personalisation fragment embedded in the page, and cache headers that were never set deliberately. Each of them turns a cacheable article into an origin request, and at a spike that is the difference between a fast page and no page.
Separate what changes from what does not
An article is static for almost all of its life. What surrounds it — the most-read list, a live counter, a signed-in user’s name — is not. Where those are rendered into the page, the whole page becomes uncacheable to serve a corner of it.
The fix is to cache the article aggressively and fetch the dynamic pieces separately after the page has arrived, or to assemble them at the edge. It is the single highest-value architectural change available to a publisher, and it is usually a front-end change rather than an infrastructure one.
Protect the part that cannot be cached
- Serve a stale page rather than an error.If the origin is struggling, a version of the article from thirty seconds ago is a complete answer for a reader. Configure the cache to do this before you need it.
- Keep publishing working while reading is saturated.The newsroom has to be able to post the next update during the spike, which means the editorial path must not share a pool with the public read path.
- Rate-limit expensive endpoints.Search and archive queries cost far more per request than an article and are the usual way an origin is exhausted while the cache is doing its job.
- Have a lightweight version ready.A stripped page — text, no third-party scripts — that can be switched on under load, is worth building before the day you need it.
Images are most of the bytes
Images and video are the bulk of a news page’s weight, and they are the easiest to fix: correctly sized variants, modern formats, and lazy loading below the fold. It reduces cost at every level simultaneously, and unlike most optimisation it is unambiguously good for readers on slow connections — who, during a breaking story, are much of the audience.
Where this fits
The service is Compute Solutions, and the sector context is News and Publication. The delivery path in front of it is Network Solutions; where the platform is being designed rather than tuned, see designing for an unscheduled peak, which is the same problem in another sector.
