Gate

A limit that is only approximately enforced is not a limit. Across many stateless instances, two containers can read the same bucket and both decide there is room, so a 100-request cap quietly issues 140 — and nothing in a normal load test notices, because every response looks correct. The usual fix is a Redis lock or a single coordinator, which trades the bug for a new single point of failure and a second datastore to run.

Each key is one DynamoDB item, and every consume is a strongly consistent read followed by a write conditioned on the item's version, so only one instance can win a given state change. Conflicts retry with jittered backoff and, when retries run out, the request is rejected rather than admitted — the system under-issues at the tail and never over-issues. Multi-level token budgets reserve user, agent and org quotas all-or-nothing inside a single transaction, and a bulkhead, circuit breaker and timeout wrap only the rate-limit store, with a classifier so per-key contention cannot trip a process-wide breaker.

Three correctness invariants — the bucket never over-issues, exactly one create per idempotency key, the quota never over-admits — run as a load scenario in CI on every change, alongside 251 unit and 71 integration tests. The same suite ran against a Terraform-deployed stack on AWS with real DynamoDB: 21,697 requests, zero errors and zero degraded decisions. The bucket allowed exactly 80 requests where the math permits 80, one key out of ten concurrent writers was created exactly once, and the quota admitted exactly its one-million-token ceiling.