Real-time trading platform

Why Paragon returned

Paragon had worked with two development shops before us. One produced little visible progress after months of invoices. The other delivered working features, but the system was unreliable and difficult to change.

Our first engagement was different. We gave honest estimates, delivered Paragon Social Apps within the agreed timeline, and demonstrated a complete product. That earned enough trust for Paragon to bring us the trading platform.

A prototype we couldn't repair

The prototype consumed Binance USD-M futures data in the browser. It calculated proprietary trading signals from price, volatility, market regime, and user inputs. Users could then submit an intent to trade, which the backend executed through the Binance API.

The browser retained and processed far more data than it should have. It froze within an hour and required a manual restart. During that interruption, a trader could miss an entry or fail to exit a position at the intended time.

The implementation was a flat collection of large JavaScript files with no useful module boundaries. We kept its UX and user flows as the product specification, but discarded the code. This was one of the rare cases where a full rewrite carried less risk than incremental repair.

Designing around the workload

We moved the heavy data work to the server and kept the browser as a display and control surface. The system separated Binance ingestion, market-data processing, signal computation, trade execution, and frontend delivery so each workload could scale independently.

Binance WebSockets supplied aggregate trades, candlesticks, and ticker updates. Processing workers built candles across timeframes and filled gaps through the Binance REST API. Signal workers evaluated the proprietary formulas for each trading pair and timeframe.

We located the ingestion servers in Japan, close to Binance. This, alongside other decisions we made, kept the source to backend-for-frontend latency low, under 100ms.

A four-person team delivered the system in four months. The team included two backend engineers, one frontend engineer, and a lead full-stack contributor.

Why Redis Streams fit

Redis Streams carried events from ingestion into the processing workers. Consumer groups gave us acknowledgements and message claiming, while sorted sets held aggregated candle data.

Redis also provided the latency and throughput the workload needed without another infrastructure system since we already were going to use it for caching.

We accepted weaker long-term durability because recent market data was replaceable through the Binance REST API. Old data had little product value in this case since the client didn't want to do backtesting within this platform. That was a separate concern.

What shipped

The backend for frontend used Socket.IO to broadcast live data and accept trading commands. Wallet-based JWT authentication protected access, while rate limiting and observability covered the production boundary. LyteNyte Grid Core kept the browser responsive while it rendered the live data.

The finished system consistently processed roughly 3,000-4,000 market-data events per second across 400-500 trading pairs. The hourly memory failure did not return during development or beta. The system consumed live data, calculated signals, relayed them to users, and placed trades end to end.

Where the engagement stopped

We also laid the foundations for payment integration and paid-tier authorization. The client's budget ended before those commercial features were complete, so the platform did not reach a public launch.