Refresh on the publisher's clock

The weather API's cache refresh runs every hour at minute 27. Not on the hour — at :27. The number looks arbitrary and is the least arbitrary thing in the file.

Minute 27

The upstream is ARSO's observation feed, which the project's decision record describes as publishing on a roughly 25-minute cycle. The cron — 27 * * * * — sits just past that beat, with the record naming the offset as a safety margin over the publish cycle. Schedule the same job on the round hour instead and you refresh at whatever point in the upstream's cycle the hour happens to land — worst case, moments before fresh data appears, after which you serve the previous reading for another full hour. Round numbers maximize staleness because freshness is relative to when the publisher publishes, not to when your clock looks tidy. The refresh runs on the upstream clock, not ours.

There's a quieter rule in the same service: the refresh job catches its own failures, logs them, and keeps the last good data instead of throwing. A cache warmed on the publisher's rhythm can afford to miss a beat.

The TTL that drifted

The cache lives for an hour in code — 60 * 60 * 1000 — a small multiple of the publish cycle rather than a number picked for niceness. A TTL detached from the cycle fails in one of two directions: too short and you refetch data that cannot have changed yet; too long and you re-serve readings the publisher has already replaced.

And here's the honest wrinkle: the decision record still says ninety minutes. The window changed at some point and the code moved while the record didn't — I only found the disagreement rereading both for this post. The mismatch doesn't weaken the scheduling logic, but it's a live specimen of the thing I keep writing about: two homes for one number, drifting.

The Monday version: for one thing you cache today, find out when its upstream actually publishes, then look at your refresh schedule next to that number. If you can't find out when it publishes — that's worth knowing too.

All of this assumes the upstream has a rhythm at all; event-driven sources make the point moot. And a publisher can change its beat without telling anyone. The cron will keep firing at :27 out of loyalty to a cycle that may no longer exist — and I don't yet have a way for the schedule to notice.