Refresh interval cost
Freshness has a price. A feature that the model reads 4,000 times/s costs 52 USD/mo with a 25 s refresh. A 10 s refresh needs about 10 database vCPU and goes over 60 USD/mo.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Value refreshed every 600 s | Value refreshed every 25 s |
|---|---|---|---|
| p99 latency | under 150 ms | 55 ms Pass | 94 ms Pass |
| Error rate | under 0.1% | 0% Pass | 0% Pass |
| Data age | under 30 s | 179.9 s Fail | 25.3 s Pass |
| Monthly cost | 40 USD/mo | 52 USD/mo |
Key numbers
| Number | Value |
|---|---|
| Default time to live of a cache entry | 60 s |
| Reads per second, one database vCPU | 15,000 reads/s |
| Cache read, median | 0.1 ms |
TTL 5 minutes · 12 lookups/h · old answers up to 5 minutes
How it works
A cached value is recomputed when it expires. The shorter the time to live, the more often the system recomputes it, and each recompute costs database CPU. Freshness is not free.
In the mini board a fraud model reads a card velocity feature 4,000 times each second. A cached value is recomputed from the event database when it expires. The model loses its gain when the value is older than 30 s. A time to live of 600 s is far too old, and the model fails the freshness limit.
The cost curve is steep. At a 25 s refresh the database needs 7 vCPU, and the system costs 52 USD/mo. At a 10 s refresh it needs about 10 vCPU, and the cost goes over the 60 USD/mo budget. Both meet the age limit, but only one meets the budget.
So do not pick the freshest value that you can afford. Ask what age the reader can accept, add a safety margin for the refresh itself, and set the interval just inside that. A refresh in the background also helps, because readers never wait for it.
In the levels you tune the time to live and the database size together.