Speed is the invisible edge in trade copying. A few hundred milliseconds can be the difference between the intended entry price and meaningful slippage. MirrorLink uses WebSocket connections to keep that gap as small as possible.
Polling vs WebSockets
Traditional copiers poll the master account every few seconds, asking “any new trades?” repeatedly. This creates latency equal to half the polling interval on average, plus processing time. WebSockets flip this model: the connection stays open and the server pushes events the instant they occur.
| Approach | Avg detection latency | Bandwidth usage | Connection overhead |
|---|---|---|---|
| REST polling (5s) | ~2,500 ms | High (repeated requests) | New connection each poll |
| REST polling (1s) | ~500 ms | Very high | New connection each poll |
| WebSocket | <50 ms | Minimal (event-only) | Single persistent connection |
How MirrorLink’s pipeline works
- Event detection: The MT5 WebSocket bridge or cTrader Open API stream pushes a trade event to MirrorLink the moment a position opens, modifies, or closes.
- Normalisation: MirrorLink translates platform-specific fields (symbol naming, lot conventions, order types) into a common format.
- Rule evaluation: Your route rules—lot sizing, symbol filters, session windows, risk caps—are checked in-memory with no database round-trip.
- Execution: The instruction is dispatched to each slave via the fastest available channel: cTrader Open API for cTrader accounts, or the MT5 WebSocket bridge for MetaTrader accounts.
- Confirmation: The slave’s fill is logged and the dashboard updates in real time via a second WebSocket channel to your browser.
Reconnection and resilience
Network interruptions happen. MirrorLink implements automatic reconnection with exponential backoff. If the WebSocket drops, the system reconnects within seconds and reconciles any events that arrived during the gap. Missed events are replayed from a short-lived buffer so no trade is lost.
What this means for you
You get sub-second trade replication without running custom infrastructure. The Logs page shows timestamps for every stage of the pipeline so you can verify latency yourself. Most users see end-to-end times under 200 ms from master event to slave fill.