A different clock.Refresh the archive.
Not every visit.

01 / FIELD NOTESWhere this showed up in Hades

The published account describes a scheduled function that refreshes the archive once a day and caches the result. Page loads read the saved list.

The change separates two events: someone visits the site, and the site refreshes its archive metadata. The first no longer has to cause the second.

This is about the archive list, not relaying or caching the live streams. It is also not proof that every part of the site has unlimited capacity.

02 / FIELD NOTESMake the request count visible

The numbers in this experiment are assumptions you control, not measurements of Hades. “Calls per refresh” allows for a refresh that needs several upstream requests. The source does not give that count.

Within the example, fetching on every page view costs visits × calls per refresh upstream requests. Scheduled fetching costs refreshes × calls per refresh. Cache reads still grow with visits; they have not vanished because the upstream line is flatter.

Editorial clarification: the original article described equal backend cost for ten and ten thousand visitors. That is too broad. Separating archive refreshes can hold this particular upstream operation steady, while cache reads, compute, bandwidth, and other work still vary. Those remaining costs and limits need their own checks.

03 / FIELD NOTESThe general pattern

The original article identifies three ingredients: repeated fresh work, a limit or cost attached to it, and enough traffic to expose the dependency.

A video list is a good example because many visitors may need the same information. A product catalog can have a similar shape. But not every response is interchangeable: an account-specific record or a time-sensitive action needs its own freshness and access rules.

That is a design question before it is a caching question. What can safely be reused, who can read it, and how long may it be out of date?

04 / FIELD NOTESA saved result still needs failure behavior

A refresh can succeed, fail while an older result remains, or fail before any result exists. Those cases should not all produce the same “up to date” label.

Use the figure's cache-state controls to inspect the difference. They are planning scenarios, not a reconstruction of Hades's undocumented error handler. The supplied article does not establish retry behavior, stale-data retention, or how the very first cache entry is populated.

05 / FIELD NOTESQuestions to ask before the busy day

Start with the page people are most likely to visit. Find out whether it makes a fresh third-party request on every load, what that request costs or consumes, and what the visitor sees when it fails.

Then inspect the refresh path just as carefully as the read path. Who refreshes the data? Can overlapping refreshes multiply the work? Is an old result shown honestly? What happens when nothing is cached?

The useful outcome is not “we added caching.” It is knowing which dependency has been removed from the page-view path, and which limits still need attention.

Read the Hades project for the surrounding viewing experience, or the progressive-enhancement article for the separate question of what a page should do when an enhancement is unavailable.