We've been building trading platforms and financial software for over a decade. Not the kind you'd use to buy a few shares on your phone. The kind where professional traders sit in front of six monitors, watching real-time data streams, executing strategies, and depending on the software to work flawlessly during the most volatile moments in the market.
That experience has shaped how we think about software in general. The lessons from trading platform development apply to any application where reliability isn't optional and data needs to be accurate every single time.
Real-Time Is Harder Than It Looks
Every developer thinks they understand real-time until they actually build it. Displaying a number that updates every second sounds trivial. Displaying 500 numbers that update 4 times per second, across multiple screens, while the user is also submitting orders and the system is performing calculations on every tick, is a completely different problem.
The first trading dashboard we built had a memory leak. Not a dramatic crash, but a slow accumulation of event listeners that made the browser tab use 4GB of RAM after a full trading day. Users were restarting their browsers every few hours. We tracked it down to WebSocket message handlers that weren't being properly cleaned up when components unmounted. Each price update created a tiny orphaned subscription. Multiply that by thousands of updates per hour across hundreds of symbols, and you've got a problem.
That was the first lesson: in real-time systems, every subscription needs a corresponding unsubscription. Every listener needs a cleanup. Every timer needs a clear. The browser's garbage collector won't save you at this volume.
The Data Never Stops (Until It Does)
Market data feeds are relentless. During market hours, prices stream in continuously. Your system needs to process, filter, and display them without falling behind. If your rendering can't keep up with the data rate, you get a backlog that manifests as delayed prices. In trading, a 2-second delay can cost real money.
We learned to decouple data ingestion from rendering. The backend receives and processes all data in real-time. The frontend subscribes only to what's currently visible on screen. When a trader switches watchlists, we unsubscribe from the old symbols and subscribe to the new ones. The first version pushed everything to every client. With 50 concurrent users watching different subsets of 3,000 symbols, the server was doing enormous unnecessary work.
Then there's the opposite problem: the data stops. Market data providers have outages. Network connections drop. We implemented heartbeat monitoring on every data connection. If we don't receive a heartbeat within the expected interval, we flag the feed as potentially stale and show a visual indicator to users. A trader making decisions on 30-second-old prices could lose real money.
Market Conditions Are the Test Suite You Didn't Write
Normal market conditions are easy. The hard part is what happens at the edges.
Market opens. In the first 30 seconds of trading, data volume spikes to 10-20x the normal rate. Your system needs to handle that burst without queuing delays. We learned to pre-warm connections and caches 5 minutes before market open so the system isn't cold-starting during the most critical moment of the day.
Halts and circuit breakers. When a stock gets halted, your system needs to know it's halted (not just "not updating"). We display halt status explicitly and prevent order submission for halted symbols. Getting this wrong means a trader submits an order that sits in a queue and executes at a wildly different price when trading resumes.
Data gaps and corrections. Sometimes the data feed skips a price, sends an incorrect value, or issues a correction after the fact. Your system needs to handle all of these without displaying wrong information or triggering false alerts. We maintain a local cache with validation logic that rejects prices that deviate more than a configurable percentage from the last known good value, then flags them for review.
Architecture That Survives the Real World
After several generations of trading platforms, we've settled on patterns that work reliably.
Backend: .NET with SignalR
We use .NET for trading platform backends because it provides the performance ceiling we need. The C# type system helps us catch calculation errors at compile time rather than when someone's portfolio value displays incorrectly.
SignalR handles the real-time communication layer. It manages WebSocket connections, handles reconnection automatically, and scales horizontally with Redis backplane. We've run SignalR hubs handling 200+ concurrent connections, each receiving dozens of updates per second, on a single server.
The calculation engines run server-side. Portfolio P&L, margin calculations, risk metrics. These involve decimal precision arithmetic that you absolutely do not want running in JavaScript on the client side. A floating-point rounding error in a margin calculation could result in an incorrectly approved trade.
Frontend: Angular with DevExtreme
The frontend is where traders live all day. Angular's structure handles the complexity of multi-panel layouts with independent data streams. Each panel (watchlist, chart, order entry, positions, order history) is its own component with its own data subscriptions.
DevExtreme's DataGrid handles the tabular data display. When you need to show 2,000 rows of order history with sorting, filtering, and real-time status updates, virtual scrolling is essential. We tried building custom grids twice in earlier versions. Both times we replaced them with DevExtreme because the edge cases consumed too much development time.
Testing with Live-Like Data
Unit tests are necessary but not sufficient for trading software. You can have 100% code coverage and still miss bugs that only appear with real market behavior.
We built a market replay system that captures a full day of live market data (price ticks, volume, halts, corporate actions) and replays it at any speed. This lets us test against actual market conditions, including that chaotic market open, specific volatility events, and data anomalies.
This caught a bug no unit test would have found. During rapid price changes, our moving average calculation occasionally produced a NaN value due to a division by zero at a boundary condition. It happened once every 50,000 calculations. In testing with random data, we never hit it. In replay of a real trading day, it appeared within hours.
Reliability Isn't a Feature, It's the Foundation
Trading platforms have zero tolerance for downtime during market hours. Not "four nines availability." Not "we'll fix it in the next sprint." Zero. If the platform goes down while markets are open, traders can't manage their positions, and that's a liability issue.
This shaped our deployment and monitoring approach. We deploy during off-market hours only. We use blue-green deployments so the previous version stays running until the new version is verified. Health check endpoints verify not just "is the server responding" but "is the data feed connected, are calculations producing valid results."
What This Means for Non-Trading Projects
You might be reading this thinking "interesting, but I'm not building a trading platform." Fair. But the principles transfer directly.
The real-time patterns we developed for trading apply to logistics dashboards, IoT monitoring, and any application where data arrives continuously. The reliability practices apply to any system handling orders, payments, or medical data. And the testing approach (replay real-world data, not just synthetic test cases) catches bugs in any complex system. Whatever your domain, find out what your "market open" scenario is and test against it.
If you're building something where real-time data, reliability, or complex calculations matter, we've probably solved a version of your problem before. We'd be happy to share what we know. Get in touch and let's figure out whether our experience matches what you need.
