> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Optimize for latency

> Where end-to-end latency comes from and how to minimize it — connectivity, host sizing, and the order-entry fast paths

End-to-end latency is more than the matching engine: a request crosses the network, the API servers, and order-entry prioritization before it reaches the engine, and the acknowledgement crosses them again on the way back. Measure round trips end to end, and optimize each leg.

## Receiving market data

**Use WebSocket, not REST polling.** The [WebSocket API](/api-reference/websocket) is the recommended way to receive market data and interact with the exchange: one connection multiplexes every [channel](/api-reference/channels) 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](/guides/websocket-trading).

**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`](/api-reference/exchange/cancel-order) 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.