Every broker API imposes rate limits — a cap on how many requests you can make in a given window (say, N per second or per minute). Exceed it and the broker starts rejecting or delaying your requests with a "429 Too Many Requests" response. For an automated system polling data and placing orders, this is a hard, ever-present constraint.
Why they exist
Rate limits protect the broker's infrastructure from being overwhelmed — by buggy code, abusive clients, or just too many users at once. They're not optional or negotiable; they're a wall. A system that ignores them will, at some point, get throttled precisely when the market is fast and it's making the most requests — the worst possible time.
Staying within them
A well-built system budgets its requests: it streams data instead of hammering a poll, caches what doesn't change, and spaces out non-urgent calls. When it does hit a limit, it backs off gracefully (waiting the required interval) rather than retrying in a tight loop that digs the hole deeper. Crucially, it treats an order submission differently from a data read — a throttled order needs careful handling so it isn't accidentally duplicated.
Rate limits aren't a suggestion. A system that treats them as one gets throttled exactly when it can least afford to.
The takeaway
Rate limits are invisible until they bite, and they bite hardest in fast markets. Designing around them — efficient data usage, graceful backoff, safe order retries — is part of the unseen engineering that keeps an automated tool reliable under load. It's the kind of resilience work baked into a system like NoVo so the plumbing doesn't fail when the tape gets loud.