Trading systems development starts with how fast it has to be

A platform and a bot have budgets more than a thousand times apart

On a trading platform, a response within about 300 ms is probably fine, because a person clicking an order cannot feel the difference below that. A Solana arbitrage bot I built and run averages about 260 µs from detecting an opportunity to a signed transaction. That is my own figure for its average, and its scope ends at signing, not at the transaction landing.

Inside that time the bot sizes the position, builds the transaction and signs it, because it is competing with other bots for the same opportunity. A trading platform is not in that race and does not need that work. The engineering it would take is better spent on the parts of the platform its users notice.

A trading platform that feels slow usually has a front-end problem

When users say a platform feels slow, the order path is rarely the cause. The usual causes are in the browser front end: no feedback after a click, a spinner that blocks the page, long lists rendered in full, and polling that keeps running in tabs nobody is looking at, which loads the weaker machines most.

The fixes are specific. I keep only the visible rows of a long or streaming list in the page, load heavy components after the first paint, and pause polling while a tab is hidden.

I also time each stage of an order and write those timings from a background worker, off the request path, so recording them never delays a trade. The front end and the order path are then measured separately, and a speed figure I have not measured is not one I publish.

On a platform, the time is better spent on data users can trust

A real-time feed has one correctness contract: tell the consumer exactly what is missing. I give every event a global sequence number. A client that connects replays from the durable store up to the head captured when it connected, then switches to live events, so recovery completes instead of jumping ahead. A hole that cannot be filled is sent as an explicit gap event, never skipped.

The case that breaks this is the cold start. On a trading-data product I build and run, a poll from the very start of the feed returned 7 events and marked the response complete while the durable store held 454. A new consumer would have believed it was current, with nothing to alert on. I now test the cold start as hard as the steady state.

When the budget is microseconds, I take work off the path before making it faster

The cheapest microseconds are the work a bot no longer does at decision time. I pre-build everything that can be prepared in advance and patch only what changes when an opportunity appears. A success-rate gate sits beside the speed target, so a faster path cannot quietly buy failed trades.

Allocations come next. I count them per message before reaching for a faster language or new hardware: one decoder per batch rather than one per message, slices sized once, and a copy made only of the data that is kept. Each change is measured on its own.

A faster path that is wrong is not faster

A data race on the hot path is a latency bug and a correctness bug at once. Values the hot path reads often become atomic, nothing is written while only a read lock is held, and the race detector and contention profiling find what review misses.

I also write down the optimisations I rejected and why, so the next engineer does not rediscover them in production. A hand-written replacement for a tuned arithmetic library came out slower than the library it replaced, so it was dropped. Price estimates err towards not trading, so an inaccurate quote costs an opportunity rather than a bad trade.

Where speed does matter, the moment that costs is usually the first trade after a quiet period rather than the average, and I go into that in more depth in Insights.

You set the budget with me, and the work arrives as reviewed pull requests

A workflow review comes first: I look at how a change moves from ticket to production on your team, where your order path spends its time, and what my software factory can take on. You leave with a plan either way.

If you go ahead, the factory does the volume, I review what it produces, and you set the priorities without constant meetings.

Start with a workflow review of your order path and where its time goes.