For an intraday algo, latency is not a vanity metric. A momentum strategy that decides at the close of a one-minute candle competes with everyone else who saw the same candle. If your order reaches the exchange 2 seconds later than theirs, you trade at a worse price — every single time. That cost is invisible in a backtest and very visible in your monthly P&L.
This post walks through what actually happens between an AlphaSync strategy firing a signal and the order being acknowledged by NSE, where the milliseconds go, and the engineering choices that keep the 99th percentile under 450ms.
The anatomy of an order
Every automated order on AlphaSync travels through five stages:
- Signal evaluation — the strategy engine decides to trade.
- Pre-trade risk — capital limits, drawdown caps, exposure and rate checks.
- Order construction — instrument, quantity, order type, algo ID tagging.
- Broker adapter — the HTTPS call to your broker's order API.
- Exchange acknowledgement — the broker forwards to NSE/BSE and returns an order ID.
Here is roughly where the time goes on a typical liquid F&O order:
| Stage | Typical | p99 budget |
|---|---|---|
| Signal evaluation | 2–8 ms | 15 ms |
| Pre-trade risk checks | 1–3 ms | 5 ms |
| Order construction & tagging | <1 ms | 2 ms |
| Broker API round trip | 180–280 ms | 380 ms |
| Internal queueing & network | 10–30 ms | 48 ms |
| Total | ~250–320 ms | <450 ms |
The uncomfortable truth is in row four: the broker API round trip dominates everything. Retail algo infrastructure in India routes through broker order APIs — that is how the regulatory framework works. You cannot colocate your way around it. What you can do is make every other stage so fast it barely registers, and squeeze the broker leg as hard as the protocol allows.
Keeping pre-trade risk under 5ms
Risk checks are the easiest place to accidentally burn 100ms. A naive implementation reads positions from a database, recalculates exposure, and queries today's realised P&L — three round trips before a single order goes out.
Our risk engine keeps the entire risk state in memory: capital deployed, per-strategy drawdown, daily loss counters, position Greeks. The state updates on every fill event rather than being recomputed on demand. A pre-trade check is then a handful of comparisons against already-warm numbers — consistently 1–3ms, under 5ms at p99. The database is written to asynchronously for the audit trail; it is never on the order path.
Squeezing the broker leg
Three things matter more than everything else combined:
1. Persistent, pre-warmed connections
A cold HTTPS call pays for DNS, TCP and TLS setup — easily 150ms before any trading happens. Our broker adapters hold persistent connection pools to every broker, kept warm with periodic health checks. An order reuses a hot connection and pays only the request itself.
2. Per-broker adapter tuning
Broker APIs are not interchangeable. They differ in auth schemes, rate limits, payload shapes and — significantly — response times by order type. We benchmark every adapter continuously and publish the numbers internally. When a broker's p99 drifts, we see it within minutes, not after a trader complains.
3. Doing nothing else on the hot path
Notifications, analytics events, Telegram alerts, P&L recalculation — all of it is queued and processed off the order path. The hot path does exactly three things: check risk, build the order, send it.
Measuring honestly: why p99, not average
Averages hide the orders that hurt. If 99 orders take 250ms and one takes 4 seconds, the average looks fine — but that one order was probably during a volatility spike, exactly when the price was moving fastest and the late fill cost the most.
We track p50, p95 and p99 per broker, per order type, per market session, and alert on budget breaches. The 450ms figure we publish is the p99 — the worst 1% of orders, measured from strategy signal to exchange acknowledgement, across the trailing month.
What this means for your strategies
- For minute-bar and above strategies, our latency is effectively negligible — slippage from spread and liquidity will dominate.
- For fast scalping systems, enable slippage guards: AlphaSync can reject a fill if the price has moved beyond your tolerance between signal and quote.
- Watch the execution-quality report (Analytics → Execution) — it shows your real signal-to-fill latency and realised slippage per strategy, so the backtest assumptions stay honest.
Latency engineering is not glamorous. It is connection pools, in-memory state, queue discipline and dashboards. But it is exactly the kind of unglamorous work that separates infrastructure you can trust from a script on a laptop.