Skip to content

Message throttling

How trading gateways limit bursts of order messages, and why a rejected cancel, a delayed cancel and a disconnected session have different consequences.

Message throttling limits how quickly a trading system can send or process messages such as new orders, amendments and cancellations. It protects shared order-entry capacity from bursts. For a market-making strategy, a burst of quote updates can also use up the capacity needed to withdraw a stale quote if those requests share a limit.
A throttle measures traffic against a time budget. An order-to-trade ratio compares order activity with executions. A short burst can hit a message throttle even on a day with a low order-to-trade ratio.

How a token bucket handles a burst

A token bucket stores permission to send messages. In a simple version each message costs one token, tokens refill continuously at rate rr, and the bucket stores at most BB tokens. If the last batch left bb tokens and Δt\Delta t seconds have elapsed, the next batch sees

bbefore=min⁡{B,b+rΔt}.b_{\mathrm{before}} = \min\{B, b + r\Delta t\}.
For this reject-only example, process messages in arrival order, subtract one token for each admission and immediately reject any message that arrives with less than one token available. A rejection leaves the balance unchanged and creates no queued request. A full bucket permits a burst of BB messages, while refill governs the long-run rate under continuous demand. The same budget can be used to pace a queue instead, by holding a message until it has enough credit. IETF RFC 3290, Appendix A.4.
Take a fictional bucket that starts full with three tokens and refills at two tokens per second. At time zero, three of four simultaneous requests consume the initial tokens. The fourth is rejected. Half a second later exactly one token is back, so only one of two new requests gets through. At one second the same refill admits the sole new request. The throttle admits five messages and rejects two. Admission here means passing this rate check. The message can still face order validation before the matching engine acts on it.
Fictional token bucket. At 0, 0.5 and 1 second, 4, 2 and 1 messages arrive. The bucket admits 3, 1 and 1 and rejects 1, 1 and 0. Its balance falls to zero after each batch.
Fictional token bucket. At 0, 0.5 and 1 second, 4, 2 and 1 messages arrive. The bucket admits 3, 1 and 1 and rejects 1, 1 and 0. Its balance falls to zero after each batch.
The rising lines show continuous refill. Each vertical drop spends the tokens available when a batch arrives. Rejected messages use no tokens.

What happens at the limit

HKEX’s Orion Central Gateway for the securities market uses fixed one-second windows aligned to its clock. In its binary trading protocol the business-message limit applies per Comp ID, the client identifier. Excess messages receive a Business Message Reject, and HKEX may drop the session for excessive violations. A broker can queue excess traffic in its own system for a later window. Once the gateway has rejected a message, sending it again requires a new submission from the client. HKEX OCG-C FAQ, HKEX OCG-C Binary Trading Protocol v3.2, §6.12.
An exchange can also apply backpressure by pausing reads. Cboe documents an optional U.S. equities port setting that pauses reading messages, including cancels, when specified rate thresholds are exceeded and resumes when the timer expires. This delays when the venue can act on the cancel. An explicit throttle reject means that request did not take effect. If the session drops before a response arrives, the client may have to reconcile outstanding requests with the venue. HKEX documents cancel on disconnect separately as an optional feature for specified scenarios, with conditions on when it triggers and which cancellations succeed. Cboe port controls, HKEX OCG-C Binary Trading Protocol v3.2, §6.11.
For an execution replay, the practical inputs are the counted message types, which traffic shares a limit, whose clock defines arrival and what the interface does at the threshold. A delayed or rejected cancel can leave an order exposed while the market moves. The Live Execution Monitoring lesson works through how to account for outstanding quantity during that uncertainty. The preview is public and the full lesson requires membership.

Sources

Last updated
  • trading infrastructure
  • rate limiting
  • order entry
  • token bucket
← Back to the glossaryBack to top ↑