Receiving market data
Use WebSocket, not REST polling. The WebSocket API is the recommended way to receive market data and interact with the exchange: one connection multiplexes every channel and order entry, and updates are pushed the moment they happen. REST is fine for bootstrapping state, but polling it adds a full round trip to every observation. Colocate in Asia. The exchange is hosted in Asia, so network round-trip time is dominated by your distance from it. Running your trading systems in an Asian region gives the lowest and most stable round trips. Provision enough hardware. A host that cannot drain its socket promptly falls behind, and the server force-disconnects clients whose connections stay saturated. Use at least 2 CPU cores and 4 GB RAM; 4 cores and 8 GB is preferred for busy accounts or full-depth market-data subscriptions. Keep the read loop light — parse and hand off, and do strategy work on other cores.Placing and canceling orders
Trade over the socket. Order entry over the existing WebSocket connection skips connection setup entirely — see Trade over WebSocket. Use ALO for the fastest placement. Order entry applies a taker speed bump of 50 ms: any order that could remove liquidity — a non-post-only place, or a modify whose time-in-force allows taking — is held for 50 ms before sequencing.ALO (post-only) orders can never take, so they skip the speed bump and go straight to the engine. If your flow is maker-only, submit ALO: it is the fastest path in, and modifies of an ALO order keep the fast path too. (The 50 ms value is operator configuration and could be tuned in the future.)
Cancels are prioritized. Cancel requests are processed on a dedicated lane ahead of queued order placements, so pulling quotes stays fast even when order entry is busy. cancelOrder (or a batch of them) beats a burst of competing placements to the engine.
Use client IDs to skip a round trip. Supply a clientId when placing and you can cancel by clientId immediately — no need to wait for the acknowledgement to learn the server-assigned orderId. Client IDs also let you correlate orders-channel events with in-flight requests. A clientId must be unique among your live orders (reuse after the order reaches a terminal state), and an account can hold up to 10,000 live client IDs.