Execution Infrastructure
Sub-millisecond execution, institutional infrastructure.
Execution quality determines whether a valid signal becomes a profitable trade. The BabahAlgo execution infrastructure is engineered for minimal latency, maximum reliability, and complete auditability at every stage of the order lifecycle.
Performance
Latency architecture
ZeroMQ bridge specifications
The ZeroMQ bridge is the critical link between the strategy engine (running in Docker on Linux) and MetaTrader 5 (running on Windows). Communication occurs over TCP sockets on localhost, eliminating network latency entirely. Messages are serialized using a compact binary protocol that encodes trade commands (OPEN, MODIFY, CLOSE) with full parameters (symbol, direction, lot size, stop-loss, take-profit) in under 100 bytes per message.
The bridge operates in a request-reply pattern: the strategy engine sends a command and blocks until the MT5 EA confirms receipt and processing. This synchronous pattern ensures order integrity -- no command is lost or duplicated. Measured round-trip latency in production consistently falls below 2 milliseconds.
<2ms
Round-trip latency
<100B
Message size
TCP
Transport
REQ/REP
Pattern
Connectivity
Broker integration
MetaTrader 5 serves as the broker connectivity layer. The MT5 expert advisor is a stateless order executor -- it receives commands from the ZeroMQ bridge, validates them against the broker's trading conditions, and submits them to the liquidity pool. The EA performs pre-submission checks including symbol availability, minimum lot size compliance, margin sufficiency, and trading hours validation.
Order types supported include market orders (immediate execution), pending limit orders, and stop orders. All orders include attached stop-loss and take-profit levels set at the time of submission. Position modifications (stop adjustment, trailing stop ratchet) are handled as separate MODIFY commands through the bridge.
Fill confirmations are returned to the strategy engine through the same ZeroMQ channel, including the actual fill price, slippage (if any), and the broker-assigned ticket number. This data is logged to PostgreSQL for reconciliation and slippage analysis.
Infrastructure
VPS infrastructure
Dedicated hardware
The trading engine runs on a dedicated VPS with guaranteed resources: no shared CPU cores, no memory overcommitment, and NVMe SSD storage for database I/O. The server is located in a data center with redundant power, cooling, and network connectivity. Physical proximity to major broker servers minimizes network latency for the final leg of order transmission.
Network security
All external access is routed through Cloudflare Tunnel. The VPS has no publicly exposed ports. Administrative access requires Cloudflare Access authentication. Internal communication between Docker containers occurs on an isolated bridge network. The MT5 terminal communicates with the broker through its native encrypted protocol, and with the strategy engine exclusively through the localhost ZeroMQ socket.
Operations
Monitoring and failover
Health check system
A dedicated monitoring service polls all critical components every 60 seconds: ZeroMQ bridge connectivity, MT5 terminal status, broker connection state, PostgreSQL availability, and system resource utilization (CPU, memory, disk). Each check has a defined healthy/degraded/critical threshold. Degraded status triggers a warning notification. Critical status triggers the automated response protocol.
Automated response protocol
When a critical health check failure is detected, the system follows a deterministic response sequence:
- Immediately pause all new trade signals
- Attempt automated recovery (service restart, reconnection)
- If recovery fails within 30 seconds, close all open positions at market
- Disable the strategy engine and enter safe mode
- Send critical alert to the operations team with full diagnostic payload
- Log the entire incident timeline for post-mortem analysis
Uptime targets
The system targets 99.9% uptime during market hours (Sunday 17:00 ET to Friday 17:00 ET). Scheduled maintenance windows are limited to weekends when markets are closed. Unscheduled downtime triggers the automated response protocol described above, ensuring that positions are never left unmanaged during an outage.