Fintech · Custom software · 2025
Sub-100ms from price change to executed trade
A production algorithmic trading platform executing against Interactive Brokers and eToro, architected for sub-100ms signal-to-execution latency.
<100ms
price change to order execution
2+ yrs
in continuous production
2
brokers behind one execution layer
What it meant
Traders deploy a strategy in one click and it runs against live brokers, with the whole cross-broker portfolio in one place.
The challenge
Automated trading is a latency problem wrapped in a correctness problem. A signal is worth nothing if execution arrives late, and worth less than nothing if it executes twice. The platform had to detect a price change, evaluate the strategy, and place the order against external broker APIs inside a budget measured in tens of milliseconds - continuously, in production, with real money.
Our approach
We architected the platform around a messaging core that keeps the hot path clear of anything that can block it, with broker integrations to Interactive Brokers and eToro behind a common execution boundary so strategies do not care where an order lands. Strategy deployment is one click, and positions across brokers are reconciled into a single portfolio view. It has been in continuous production development for over two years with a four-person engineering team.
Tech stack
- .NET
- Blazor
- RabbitMQ
- Interactive Brokers API
- eToro API
Client profile
Private algorithmic trading platform
Client named on request, with their consent.
The budget
A latency budget for one critical path, written down as an allocation before the code exists. The whole path is held to <100ms, and the number tracked is the p99 tail rather than the mean. It is measured from t0, the timestamp carried on the event, which is stamped upstream before we receive it, through to t1 at the end of the path; starting the clock at our own ingress would hide the queue. Hops we own, each holding a share: receive + decode 8ms, evaluate strategy 15ms, duplicate check 4ms, serialize 2ms. Outside our control, capped rather than shared: broker api 45ms at most, a ceiling we do not get to hand out. Allocated in total: 74ms across 5 hops. Each segment of the bar is one hop, sized to its share of that 74ms.
budget
<100ms
p99, not the mean. measured from t0, the timestamp carried on the event, through to t1 at the end of the path.
allocation · 74ms across 5 hops
01receive + decode
8ms
02evaluate strategy
15ms
03duplicate check
4ms
04serialize
2ms
05broker api
≤ 45ms
a ceiling, not a share. the network past it is not ours.
t0 is stamped upstream, before we receive the event. starting the clock at our own ingress would hide the queue.
Want a result like this?
Tell us the problem - we’ll tell you, plainly, how we’d get there.