The runtime handle the limiter is resolved from.
Counts one request against a key and reports whether it is within the rate.
The runtime handle.
What the rate is counted per — an IP, an account, a route.
true when the caller may proceed.
Reports whether the capability is actually usable on this runtime.
The runtime handle.
true when calls will reach a real backing resource.
A capability backed by an optional resource answers false when that
resource was never provisioned. Implementations must document what each
method does in that state — degrade or throw — and must not vary it, since
a caller choosing between two implementations is relying on the answer
meaning the same thing in both.
Admission control — whether a caller may proceed right now.
Remarks
An abuse control, never an accounting record. Implementations are expected to be approximate and eventually consistent, so nothing that must balance should be derived from how many times this said yes.
What an unavailable limiter does is the one thing an implementation must not decide on its own: failing open turns a missing limiter into a capacity problem, failing closed turns it into an outage, and which is correct depends on whether the limiter is protecting an upstream or protecting a bill. It is therefore a configuration decision — see
rateLimit.failOpen.Author
Bayu Dwiyan Satria
Version
1.0.0
Since
1.0.0