Discussing the article: "Implementing a Trade Throttle and Rate Limiter in MQL5"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: Implementing a Trade Throttle and Rate Limiter in MQL5.
We build a trade throttle for MQL5 EAs using a token bucket with a priority queue to control order submission rate. Tokens refill at a configurable per‑second rate, allowing short bursts up to capacity and then enforcing sustained throughput. When the bucket is empty, requests are queued and later released by priority with FIFO tiebreaks. This keeps execution within safe limits without discarding valid signals under load.
An EA triggered by a fast-moving signal during a volatile news release can submit dozens of orders within seconds. Most brokers enforce a maximum order frequency, but they rarely publish the exact limit. When an EA breaches it, the broker may return a retcode error, delay execution silently, or ignore the request outright, producing stale fills, partial fills, or quiet rejections. The EA has no visibility into how close it is to the limit until it has already breached it.
The obvious fix, which is adding a cooldown between orders, drops valid signals during the wait. A signal that arrives two seconds after another cannot be submitted; it is simply gone. That is not a rate limit; it is a signal filter, and the strategy never intended one.
This article builds CTradeThrottle, a class implementing the token bucket algorithm, a standard rate-limiting technique used throughout network engineering and API design. The bucket holds up to N tokens. Tokens refill continuously at a configurable rate per second. Each order attempt consumes exactly one token. When a token is available, the order passes through immediately. When the bucket is empty, the order is placed into a priority queue and released as tokens return. No request is discarded solely because of rate limiting — it is queued instead, and released as tokens become available, with higher-priority requests released before lower-priority ones. Whether a delayed request remains strategically valid is outside the throttle's scope.
Author: Ushana Kevin Iorkumbul