Cachanium

Inspiration

Every time someone opens a Wikipedia article, it is served either from a fast cache or, more slowly, from Wikimedia's main servers. Caches are small, so someone has to decide which articles to keep. The standard answer is simple: keep whatever was popular in the last hour.

But attention has a shape in time. People read more in the evening, news makes pages spike and then fade, and readers come back at the same time the next day. We wanted to know: if a cache could see a few hours into the future, what would that foresight be worth?

What it does

We replay real English Wikipedia traffic hour by hour and let different strategies decide which $N$ articles to keep in a cache. Because a cache doesn't change what people read, replaying history gives an exact backtest: every strategy is scored on the same real readers.

For a cache $C_N(t)$ chosen at hour $t$ for the hour $t+h$, the hit rate is the share of views it serves:

$$ H_N(t+h) = \frac{\sum_{p \in C_N(t)} v_p(t+h)}{\sum_{p} v_p(t+h)} $$

where $v_p(t)$ is the number of views of page $p$ in hour $t$.

We compare:

Last hour (the standard rule, similar to LRU), 24-hour average (similar to LFU) and same hour yesterday;
a physics-based decay model of how attention fades after a spike;
XGBoost, which uses recent views, growth, time of day and the decay model's forecast;
perfect foresight, as the ceiling.

On 72 hours of traffic that no model saw during training, with a 100,000-page cache:

XGBoost serves 86.6% of views from cache versus 85.2% for the standard rule, and wins every one of the 72 test hours.
Misses are what cost servers work, so we measure the drop in misses:

$$ \text{miss reduction} = 1 - \frac{1 - H_{\text{model}}}{1 - H_{\text{standard}}} $$

That is 9.4% fewer requests reaching the main servers deciding 1 hour ahead, and 17.1% fewer when the cache must be decided 6 hours ahead.

The more notice a cache needs, the more prediction is worth: the standard rule degrades fastest as the warning time grows.

An interactive, article-style site lets you replay a day of Wikipedia's attention and compare the methods hour by hour. It runs fully offline.

How we built it

Data (Anay): a downloader that streams Wikimedia's hourly pageview dumps and keeps only English desktop and mobile views. It saves every hour separately, retries on network failures and resumes after interruptions. We collected about a week of hourly data, around 500 MB after filtering.
Physics of attention (Thomas): we fitted the decay of 1,429 spikes in the training days. Extra attention fades like a power law, not an exponential:

$$ \text{excess}(t) \propto \left(1 + \frac{t}{\tau}\right)^{-\alpha}, \qquad \alpha = 1.79,\ \tau = 0.87\ \text{h} $$

This gives a half-life of about 25 minutes, with a daily echo about 23 hours later.

Models and backtest (Omar): a single predict(history, now, horizon) interface for every method, a backtest across cache sizes (1k, 10k, 100k) and horizons (1, 2, 3, 6 h), and XGBoost trained only on hours before the test period.
Statistics: methods are compared on the same hours. Neighbouring hours are correlated, so confidence intervals use a block bootstrap over 6-hour blocks. We added exact sign tests and a Bonferroni correction across 48 comparisons.
Demo (Musa): plain HTML, CSS and JavaScript with no build step. It checks SHA-256 fingerprints of the results files, so it can never display numbers from the wrong run.

Challenges we ran into

Hackathon wifi versus tens of gigabytes of dumps. A network drop once made the downloader mark 86 hours as failed in three seconds. We rebuilt it to wait and retry, spread downloads across laptops, and merged the results.
Small headroom. With a 100,000-page cache, even perfect foresight beats the standard rule by only 4.6 points of hit rate. "+1.4 points" sounds small until you measure what an operator actually pays for: misses.
The clocks went back at 2 a.m. in the middle of our overnight data collection. Storing everything in UTC from the start saved us.

Accomplishments we're proud of

XGBoost is significantly better than each simple method in 46 of 48 method-by-setting comparisons, and significantly worse in none.
A fully reproducible pipeline, from raw dumps to charts, in one repository.

What we learned

Simple baselines are strong. With a small cache, the most-read pages are easy for any method; XGBoost only ties the standard rule there. The value of prediction lies in the long tail and in deciding early.
Sudden spikes are a limit of the data, not the model. A page that jumps from nothing within a single hour can't be foreseen from hourly data, and on spikes XGBoost is no better than the standard rule.
Measure the decision, not the forecast. Hit rates, misses and lead time tell an operator far more than forecast error does.

What's next for Cachanium

A transformer that reads each page's last 48 hours. In an early run it matched XGBoost, and averaging the two edged ahead of XGBoost alone in every setting.
Testing per request with Wikimedia's released caching-server traces.
Weighting pages by size in bytes, and adding a cost for swapping pages in and out of the cache.