Studio deliveryAlgorithmic trading platform · 2024–2025 · Senior full-stack engineerblackalgo.com
BlackAlgo
Real-time trading infrastructure built to hold its latency budget under volatile market load.
BlackAlgo is a studio-delivered real-time trading platform: WebSocket market data, Redis-backed live state and strategy execution built to stay consistent for many simultaneous users through volatile trading sessions. Delivered inside a previous studio, not a client contract with The SyncFlow.
- Studio
- Attribution
- Full build
- Scope
- Live
- Status
Delivered inside a previous studio. Contract terms belonged to that studio, so none are published here.
The problem
On a trading platform a stale number is worse than no number. Market data, strategy signals and position state had to reach every connected user in real time, and hold that when large numbers of people were watching the same volatile market at once.
The hard part is not rendering data quickly once. It is keeping every connected client consistent under sustained load, including the moments when load spikes precisely because the market is moving.
Constraints
The conditions the solution had to survive, not a wish list.
- Low, consistent latency
- A tight end-to-end budget covering ingestion, processing and delivery rather than rendering alone.
- High concurrency
- Many simultaneous connections, each subscribed to an overlapping but not identical set of instruments.
- Correctness under load
- Financial state cannot be visibly eventually-consistent. A dropped update is a wrong position.
- Bursty traffic
- Volatility drives message volume and user count up at the same moment.
The approach
In plain English, before the architecture.
The platform pushes rather than polls. A persistent WebSocket connection carries updates outward the moment they exist, instead of every client asking repeatedly and most answers being “nothing changed”.
Hot state lives in Redis so the read path for live data never touches the primary database. MongoDB holds the durable record; Redis holds what is needed right now.
Clients subscribe to specific channels rather than receiving everything, so per-connection work scales with what a user is actually watching rather than with the size of the market.
Architecture
The decisions that mattered, and why they were made that way.
- 01
WebSocket transport
Persistent connections with channel subscriptions, heartbeats, and reconnection with state resynchronisation, so a client that drops for two seconds returns correct rather than merely connected.
- 02
Redis on the hot path
Live prices, computed signals and session state served from memory, with pub/sub fanning updates to connected clients so the database never becomes the bottleneck at peak.
- 03
MongoDB for durable state
Historical data, user records and executed activity persisted away from the real-time path, keeping write durability from competing with read latency.
- 04
Strategy backtesting and execution
Backtesting modules and automated order execution built against the same data pipeline that feeds the live dashboard, so simulated and live behaviour do not diverge.
- 05
Frontend render discipline
The React client batches high-frequency updates and isolates re-renders to components that changed, since at this latency budget the browser itself is part of the budget.
Outcome
The platform pushes live market data, strategy signals and positions to every connected user over WebSockets, with Redis on the hot path so the real-time read path never touches the primary database.
The system held its latency budget through the traffic spikes that come with genuine market volatility, which is the condition that breaks naive real-time architecture.
Stack
- React
- Node.js
- Express
- MongoDB
- Redis
- WebSockets
More work
Lainey AI
Multi-agent AI SaaS
500 hrs
Avana
Multi-tenant booking SaaS
Full build
MyFileTracker
EU B2B e-invoicing
13 days
Tell us what you can’t staff.
Twenty minutes. No deck, no discovery sequence. If we are the wrong fit we will say so on the call and point you somewhere better.