yeah. I've run the numbers and it's a money save - is there any plausible reason not to do it?

There's no performance difference - the key change is just that you're build for all wall time as opposed to just CPU time, so if your worker is doing something like fetching from an upstream that becomes really slow for some reason, you'll likely get a spike in cost

that's useful info, thank you

You make a valid point

I'm trying to think about how to design this though. Do I have a worker on a CRON that makes the requests, calls

cache.put

for each leaderboard request. Then in my API request worker, call

cache.match

for each leaderboard request again?

or I might be 1000% overthinking this

stale-while-revalidate maybe ?

I wouldnt call the cache api on a cron worker

cron workers dont run in all locations and cache is per colo

I think I'm overthinking this, I can probably do something similar to this example? https://developers.cloudflare.com/workers/examples/cache-using-fetch/

ah I see

Yeah I'll probably want to just whiteboard this out

Is there any caching in that example ?

I can provide a tiny example in a few min

Since the past seasons won't update often, unless someone unprivates/privates themselves. So I'll want to update that like daily, but the current season will update often. But I also need to respect the 10 requests every 10 seconds rate limit I have

10 req / 10 sec ? what is that

I am thinking of a strategy like,

Firstly try finding a match in cache

don't ask me, ask Riot LOL

If not found, fetch from upstream (and cache it)

If the cache is within, let's say 10 sec, return the cached, end

is this valorant and the twitch bot lol

nah

I made the Twitch chat bot tho

If the cache is, say 1d, return cached, and wait until a refreshed version from upstream, cache it

Hm 🤔

that will reduce reqs, but the cache is local, so you need a expiration time longer than that

I'm starting to think working with KV and scheduled workers might be the play again. Here's why. For some context, in Valorant there are different "acts" aka seasons. And each season has certain ranks. For arguments sake, lets say I'm limiting this to the top 2 ranks. Radiant and Immortal 3. 1. The API I'm requesting from is paginated, and doesn't have a search function. So for each season I'll need to make a request for each page. The API limits to 200 a page, so that means making 24 requests (given there are currently 4632 players in these two ranks). 2. Later seasons I'll want fetched on a less regular cadence, since the data will be fetched significantly less often. With a scheduled worker, that's much easier to break apart. 3. With a scheduled worker, I can make all 24 requests at once, then put the entire blob of response data into KV (or some other data store if I really want).

If only you cannot bear any outdated data

Outdated data isn't terrible, since most of the time people apply will either be on the leaderboard or they won't. Someone that just reaches Immortal 3 and applies won't be a common occurrence