One change, several platform events
NinjaTrader can generate multiple events for the same logical order change. Treating each as a new instruction gives a follower a larger position than intended.
FIELD NOTES / FINTECH & CAPITAL MARKETS
One master account.
Many followers, in real time.
A trade copier that replicates a master trader's strategy across additional funded accounts in real time — with duplicate platform events resolved to one logical trade, and every replicated order matched by a globally meaningful identity.
FINTECH CASE STUDY
Trade Copier
Real-time replication.
Idempotent by design.
Trade Copier / Replication architectureSOLUTION ARCHITECTURE
THE IDENTITY PROBLEMPlatform IDs are local. Trades are not.
A master and a follower on different machines cannot use platform order IDs to agree on which order is which.
Follow the flow ↗CaptureRelayApplyMirrorLog
DOMAIN
Proprietary futures trading
WHAT WE BUILT
Real-time trade replication infrastructure
OUR ROLE
Architecture, plugin & cloud engineering
01 / THE REAL ENGINEERING PROBLEM
Copying a trade is easy.
Copying it exactly once is not.
A proprietary trading operation needed a strategy executed by one master trader replicated across additional funded accounts. Without automation, each trade had to be manually recreated — observed, re-entered, then stops and targets adjusted by hand.
That approach gets harder as accounts multiply. And futures markets move quickly: even a few seconds between the master's execution and the follower's can produce materially different fills.
Building a trade copier is not simply listening for an order and placing another one. Several reliability problems have to be solved before it can safely operate around live trading.
Order IDs do not cross machines
Identifiers are local to each environment, so a follower cannot use them to determine which of its orders corresponds to which master order.
Disconnection must be detected, not ignored
Follower machines lose connectivity through restarts, deployments, sleep and broker reconnects — the system has to notice rather than silently miss trade events.
02 / INSIDE THE ARCHITECTURE
Three sides.
One logical trade.
The delivered architecture, end to end.
Master capture, cloud relay, and follower application.
Master, relay, follower.
A plugin on the master captures every order and position change; a cloud signal layer authenticates and relays it; a per-instance follower plugin reproduces the trade locally under its own sizing rules.
THE REPLICATION PATH
Master trades→Plugin captures→Server relays→Follower applies→Changes mirrored→Event logged
03 / IDENTITY AND IDEMPOTENCE
Duplicate events
cannot mean duplicate exposure.
Every trade is matched by a globally meaningful identity rather than a machine-local order ID, so a follower always knows which of its orders belongs to which master order — even across machines.
One logical change is applied exactly once. A trader may hold several related orders on the same contract, so matching a stop or target by instrument, price or proximity would risk modifying the wrong one.
Look under the hood ↘01
Capture the change at source
The master plugin observes every order and position change as it happens, rather than polling for differences.
Applied and recorded
The follower places or modifies the corresponding order and records the mapping for every later change to that trade.
Recognised and ignored
A duplicate platform event resolves to a trade the follower already acted on, so no second order is ever created.
02
Relay it authenticated
The cloud signal layer carries the event to followers with separate credentials for master and follower, and tracks sequence to detect gaps.
03
Apply it exactly once
Each follower resolves the event against its own global identity mapping, applying one logical change under its own sizing rule.
04 / THE TECHNOLOGY & THE REASON
Native where the platform is.
Cloud where the relay is.
The stack follows the boundary: plugins run inside the trading platform where order events actually occur, and the relay runs as an always-on service that neither side has to host.
C#
PLATFORM PLUGINS
C# / .NET add-ons
Master and follower add-ons run inside NinjaTrader 8, capturing order and position changes and reproducing them locally.
Why inside the platform?
Order events are only fully visible where they happen; observing from outside means inferring rather than knowing.
SIGNAL RELAY
Node.js + TypeScript
The always-on cloud service that authenticates both sides, relays events to all followers, and tracks sequence.
Why a cloud relay?
Followers are separate machines that come and go; a central relay is what lets them rejoin without the master knowing.
WS
TRANSPORT
WebSockets
Carries trade events from master to relay and relay to followers, in real time.
Why not polling?
Futures move in seconds; a poll interval is latency the strategy cannot afford.
ID
ORDER IDENTITY
Global identity mapping
Each trade is minted a globally meaningful identity that both sides share, independent of platform-local IDs.
Why not platform IDs?
They are local to each machine, so they cannot say which follower order matches which master order.
SEQ
INTEGRITY
Sequence tracking & audit trail
Detects gaps and desynchronization, and keeps a durable record of every relayed trade event.
Why track sequence?
A follower that silently misses an event is more dangerous than one that reports it is out of sync.
DK
DEPLOYMENT
Docker
Packages the signal service for consistent deployment as an always-on component.
Why containerised?
The relay is infrastructure — it should redeploy without becoming a manual operation.
The architecture diagram and narrative reproduce the supplied project documentation. This project's source material contains no product interface screens; the architecture diagram is shown in their place.
Explore the documented platform stack
- Platform integration
- C# · .NET · NinjaTrader 8 add-ons (master and per-follower)
- Signal relay
- Node.js · TypeScript · WebSockets · authenticated event delivery
- Integrity
- Global order identity mapping · idempotent event application · sequence tracking · audit trail
- Deployment
- Docker
Technology names identify the documented implementation, not partnerships or endorsements.
A CONVERSATION ABOUT YOUR EXECUTION WORKFLOW
What happens when the same
event arrives twice?
Bring one execution path that has to stay synchronized across systems. In 20 minutes, we will map where identity, idempotence and disconnection have to be handled explicitly.
20 minutes · Your platform, accounts and constraints