Our per-tenant limit was 100 requests per second, yet one tenant pushed 310 through to a partner API that then blocked us. The Redis limiter read the counter, decided in Node, then wrote back. Moving the whole token bucket into one Lua script fixed it.
Our quoting bot stayed far below request weight limits and still got -1015 Too many new orders at the worst moments. Order placement has its own per-account count limits, and our cancel-and-replace loop doubled order churn when prices moved fast. An order rate limiter and order amendment fixed it.
A single GraphQL request with deeply nested author, posts and comments fields took 40 seconds and saturated every API pod, because the schema allowed unlimited depth and list sizes. The defensive controls we added: depth and complexity limits, page caps, persisted queries and an introspection policy.
Our document tagger hit HTTP 429 constantly while sending only 40 requests a minute, far below the request limit. The token-per-minute limit was the real ceiling, inflated by an oversized max_tokens and minute-aligned bursts. How we read the headers and built a client-side limiter.
Our monitoring service polled depth and klines for 40 symbols every two seconds. During a volatile hour it hit 429 Too much request weight, kept retrying, and earned an HTTP 418 IP ban that also blocked our trading bot on the same IP. Weight-aware limiting and websockets fixed it.