A fleet-wide saving inside one service
Cloudflare’s September 18 engineering report attributes roughly 100 TB of reclaimed RAM to changes in its Pingora Backend Router, which directs cacheable requests to servers. This article revisits that report; it is not an announcement made today.
The company says statistical analysis supported reducing routing hash counts by 90%. More entries had brought diminishing benefits while consuming memory. The reported saving concerns Cloudflare’s infrastructure, not RAM removed from a visitor’s laptop. CGH has not reproduced the fleet measurements.
What developers can inspect
Cloudflare’s public Rust implementation stores the newer routing point in six bytes and exposes a configurable point multiplier. Its package manifest defines an optional v2 feature, while the version enum retains V1 as the default. These code details support inspecting the approach; they do not independently establish the company’s aggregate memory saving.
Changing routing also changes the migration risk
Cloudflare describes a staged migration that temporarily retained both routing versions. It monitored cache behavior and origin traffic before removing the old path. Moving cache requests can create extra work for origin servers, so evaluating memory alone would miss an important operational consequence.
CGH perspective
For a smaller development team, the useful starting point is a memory profile of its own workload. Record the size and number of frequently repeated objects, identify duplicated tables, and test one proposed change against a representative baseline. A dramatic result elsewhere should prompt investigation rather than become a capacity-planning assumption.
Treat deployment as part of the experiment. Define acceptable latency, errors and backend load before a limited rollout, then compare those measures alongside memory. Keep a practical rollback plan until the result is understood. Disclosure: the CGH corporate website is hosted on Cloudflare.