like SQL requests?

Technically any CF API call will add to that 1200 limit. And the CF API is the only way to query AE

can I not do something using

WHERE requests > 500

and that'd only be one request

and I can do it for all of the blobs (in a single request)

One approach could be to use queues and KV. Whenever the api is called you first check the KV. if it’s 0 then don’t execute. And if it has a value then execute it and dispatch a queue event, which would be picked up by another worker. Which would simply increment the value. Instead of a queue you can also let a durable object do this write to the KV. That way you have more control over writes and you wouldn’t have any race conditions.

Probably not because of read side sampling.

which message are you responding to?

his or mine?

Yours

what's "read side sampling"?

queues are also expensive

AE is the only product that has sampling. It basically means it will omit some records

Then use durable objects + KV.

Using AE for request tracking isn’t ideal if you’re wanting to prevent people from requesting over a certain limit. From what i’ve seen it takes anywhere from 10 seconds up to 1 minute to update, so ur users will have a window to spam requests before AE catches up

That's still a possibility

Or just DO 🙂

realistically, if my cap is at like 50,000 requests, will it matter that much?

I mean, how many requests can one possibly churn out in a minute

a lot lol

Millions

DO is atomic

very secure in my testing

& with alarms it all comes together very well

That can cost it. Cause if you have to check per request from a DO then you’re essentially have to let the DO run. But if the KV has 0 value then you don’t even execute the code to the DO which would effectively make it cheaper.

DO would be easy but it feels too costly for something so simple

What are you building. Like what’s the general idea ?

A KV read costs more than a DO read

KV’s aren’t atomic. They are eventually consistent stores.