At BitMEX, one of the most common questions they receive is about the behavior and inner workings of the offload function, also known as “Load Shedding”.
Submit an order
Order management requests (ie new/modified/cancelled orders and leverage changes) are placed in a single processing queue and processed by the BitMEX trading engine in the order in which they arrive (first in, first out).
This ensures that all requests are executed in the order received.
During special needs, delegated management requests arrive faster than they can be processed.
As the queue depth increases, requests to join the backend of the queue will wait longer, which can cause traders to wait several seconds to process their requests and receive responses.
In order to maintain an acceptable response time for traders (ie less than a few seconds), the queue has a maximum depth, after which new requests are immediately rejected with a 503 status code.
This mechanism provides immediate feedback to traders, who can then choose to resubmit or revise.
Without a maximum queue depth (i.e. an unlimited queue), the queue would become very long when the platform receives many delegated management requests in a short period of time.
When the queue is long, the response time for user requests may increase to several minutes.
The offload mechanism is a standard technique designed to prevent this from happening and to maintain a reasonable response time for the user.
When the queue for delegated management requests is not full, new requests are added to the backend of the queue as usual.
When delegated management requests are received more frequently than they are processed, the queue of outstanding requests will become full.
Delegated management requests received at this time will be rejected and the user will be notified.
Note: The specific subset of delegated management requests detailed below are exempt from offloading and will enqueue the backend as usual.
Determining which delegated administration request to accept and which delegated administration request to reject is entirely based on the depth of the queue at the time the request is received.
The backend that accepts the delegation request and joins the queue if an empty slot is available when the delegation request is received. Otherwise, it will be rejected.
Requests Exempt from Load Shedding
BitMEX has established a policy to accept certain delegated management requests even if the queue has reached its maximum depth.
This provides a backstop for traders to decide to exit positions or withdraw orders during periods of high volatility.
These operations are limited to canceling and closing orders and are outlined in the table below.
Note that all delegated management requests, including those exempt from unloading, are enqueued later in the queue.
If the queue is large, the amount of time a request will spend in the queue before being processed will increase.
An exemption request will not be processed any faster than any other enqueued request.
Requests Exempt from Load Shedding
- Cancel order (single, batch and all)
- Close limit order (cross position)
- Close market order (cross position)
- New orders (except waiver types)
- Modified orders
- Position leverage/margin changes
- All batch order requests (API)
Exempt: Order Cancellation
Web: Use the Cancel button under the Delegates tab.
API: Cancel a delegate via DELETE /api/v1/order.
Exempt: Position Close
Web: Use the “Close” or “Market” buttons under the “Positions” tab.
API: Use “close position” execInst on POST /api/v1/order without orderQty.
Closing a position without a quantity will be interpreted as your entire position size.
Closing orders containing quantities are affected by unloading, as are batch orders, even if only one order is submitted.
BitMEX works every day to improve system performance and reduce the occurrence of uninstalls.
As BitMEX provides improvements and the throughput of the transaction engine increases, the queue will process faster.
With this extra performance, BitMEX periodically increases the maximum queue depth to allow more delegates to be placed without causing unloading.
BitMEX has done this three times in 2018 and once in 2019.