Token Bucket Rate Limiting for Queued MQL5 Trade Requests
Summary
The article describes an MQL5 execution utility that controls order submission frequency with a token bucket. Tokens refill continuously at a configured rate up to a capacity, allowing an initial burst while limiting sustained throughput. When no token is available, the request enters a bounded priority queue; higher-priority requests are released first, with enqueue time breaking ties. The design also outlines request cancellation, status reporting, and timer-based queue draining.
The framework is presented as an infrastructure layer rather than a complete execution engine. It distinguishes dispatched requests from confirmed fills and notes that its recent-dispatch count is based on a finite timestamp ring buffer, which can undercount if entries are overwritten. Queuing avoids dropping signals solely because of pacing, but delayed signals may become stale, and a finite queue can overflow during prolonged bursts. The article describes an accompanying demonstration and assertions for algorithm behavior, while emphasizing that broker-specific order validation, lifecycle tracking, rate settings, and expiry policy need deliberate handling.
Key ideas
- A token bucket permits bursts up to its capacity and constrains ongoing request throughput through its refill rate.
- Fractional tokens allow accurate sub-second refill without relying on fixed timer intervals.
- Requests that cannot pass immediately are queued and ordered by priority, with FIFO ordering among equal priorities.
- Dispatch counts do not confirm broker acceptance or trade fills, which require separate tracking.
- Queue capacity, signal expiry, order validation, and broker-specific settings remain execution-layer responsibilities.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.