Nexus Trader

Context

Nexus Trader is an automated trading platform I built to solve a personal pain point: trading workflows require real-time visibility, automation, and structured access to market data — but most solutions are either expensive SaaS platforms or disconnected sets of scripts and spreadsheets. I wanted to prove that a single full-stack application could replace the chaos of tabs, terminals, and manual logs.

The Problem

Every trading day meant juggling: a broker web interface for orders, a spreadsheet for tracking positions, a terminal for market data feeds, and a notebook for recording decisions. There was no unified view of portfolio state, no automation for repetitive actions, and no historical data to analyze past performance. The mental overhead of context-switching between these tools was higher than the actual trading work.

Why This Matters

For anyone who manages active positions, the gap between "market moved" and "I reacted" is where money is lost. The goal was not to build a trading bot that replaces human judgment — it was to build a system that removes the friction between deciding and acting, while keeping the trader in control.

Architecture Decision: Socket.IO over Raw WebSocket

The first technical decision was how to push real-time market data to the dashboard. Raw WebSocket was the obvious choice, but I chose Socket.IO instead. The reason: automatic reconnection handling. In trading, a dropped connection during market hours is not a bug — it is a risk. Socket.IO provides built-in reconnection with exponential backoff, rooms for broadcasting to multiple clients, and fallback transports if WebSocket fails. The trade-off is ~15% more overhead per message, which is negligible for market data that updates every 500ms.

The Python Worker Pattern

Market data processing and trade signal calculation are CPU-bound tasks that should not block the main Node.js event loop. I separated these into Python workers that communicate with the server via a Redis-backed task queue. This means: the Node.js server stays responsive for dashboard updates, Python processes market data asynchronously, and if a worker crashes, the system continues running with the last known state. The cost is operational complexity — now there are three runtimes to monitor instead of one.

Database Strategy: MySQL for History, In-Memory for Now

Financial data has two very different access patterns: historical queries (analysis, reporting) and real-time state (current positions, live prices). Using MySQL for both would mean slow historical queries blocking real-time updates. The solution was a split: active positions and live prices live in a Redis in-memory store, while completed trades and historical snapshots are persisted to MySQL. This means the dashboard never waits for a database query to render the current state.

What I Learned about Real-Time State

The hardest lesson was that real-time state management is fundamentally different from request-response programming. A REST API can afford to be stateless — a WebSocket connection cannot. Every reconnect must restore the full client state without missing events that happened while disconnected. I solved this with a "state sync" pattern on reconnect: the client sends its last known event ID, and the server replays all events after that ID from an in-memory buffer. If the buffer has been rotated, the client does a full state snapshot request instead.

Gallery