One of the more unexpected challenges in building the signal system wasn't the trading logic itself — it was figuring out how to get the output of that logic onto a screen I could actually watch during market hours. The Python program running on my desktop was detecting signals in real time. But a terminal window showing text output wasn't a practical way to monitor multiple stocks simultaneously while also thinking about whether to act on any of them. I needed a live visual display. This is the story of how I built it, what went wrong along the way, and what the final architecture looks like.
The Problem: Two Systems That Don't Speak the Same Language
The trading engine is written in Python and runs locally on a Windows desktop. It uses a 32-bit Python environment because the brokerage API that feeds it market data only works in 32-bit. This is already an unusual constraint — most Python development today targets 64-bit environments — and it means the available libraries are somewhat limited compared to a standard setup.
The display I wanted to build was a web interface: something I could open on any browser, on any device, that would show the current status of every tracked stock in real time. A web interface is built with completely different tools — HTML, CSS, JavaScript, React — and runs in a completely different environment from the Python backend.
These two systems have no natural way to communicate. A Python desktop program and a React web app running in a browser can't simply call each other's functions. They need a shared data layer that both can read from and write to — a middle layer that handles the synchronization between them.
Why Firebase Was the Right Choice
The obvious alternative to a shared data layer would have been to build a dedicated server: a web server running on my desktop that the React app could query via HTTP. I started down this path briefly and abandoned it quickly. Managing a local web server introduces its own set of complications — port configuration, network access, keeping the server running reliably alongside the trading engine, handling the case where one crashes but the other doesn't. For something I needed to work reliably every trading day without maintenance overhead, this was more infrastructure than the problem warranted.
Firebase Realtime Database solved the problem cleanly. It's a cloud-hosted database managed entirely by Google. The Python engine writes to it using the Firebase Admin SDK. The React web app reads from it using the Firebase JavaScript SDK. Both are connecting to the same database in the cloud — which means they communicate indirectly, through shared state, without ever needing to know about each other's existence.
The feature that made Firebase specifically right for this use case is its real-time synchronization. Unlike a conventional database where you query for data and get a snapshot, Firebase pushes updates to all connected clients the moment the data changes. When the Python engine writes a new signal to the database, the React app receives that update and re-renders the relevant part of the screen within a fraction of a second — without any polling, without any manual refresh, without any delay other than network latency.
What the Data Structure Looks Like
The database structure is intentionally simple. There are two main paths: one for current signals and one for history.
The current signals path holds one record per tracked stock, keyed by the stock's ticker code. Each record contains the stock name, current state (wave forming, pullback in progress, breakout waiting, or signal confirmed), the timestamp of the last state change, and the key metrics associated with the current state — pullback depth, tick acceleration, signal grade, and whatever secondary signal data is available. When a stock's state changes, the Python engine updates the relevant record in place. When a stock exits the tracking list, its record is deleted.
The history path receives a new entry every time any state change occurs anywhere in the system. This creates a running log of everything the system has done during the trading day — every stock that entered tracking, every stage transition, every signal that fired, every exit. The history records never get overwritten, so they accumulate throughout the day and can be reviewed afterward.
At 15:30, when the Korean market closes, the Python engine deletes all records in the current signals path. The history path is left intact for later review.
The Mistake That Cost Me a Morning
About two weeks into running the system, I noticed that the web dashboard was no longer updating in real time. Signals were firing on the Python side — I could see them in the terminal output — but the web display wasn't reflecting them. Everything looked connected and no errors were visible.
After spending most of a morning troubleshooting, I found the cause. Firebase has rate limits on its free tier, and the system had been writing to the database on every single tick received from the brokerage API — potentially hundreds of times per second during active market periods. The rate limiter had silently throttled the writes, and the dashboard had been showing stale data for hours without any visible error.
The fix required rethinking when to write to Firebase. Instead of writing on every tick, the system now only writes when something meaningful changes: when a stock transitions from one stage to another, when a signal fires, when a secondary signal updates. Individual ticks that don't produce a state change are processed entirely in memory and never written to the database. This reduced the write frequency by roughly 95% and brought the system well within the free tier limits. The dashboard has been updating in real time without interruption since.
This experience reinforced something I've had to relearn multiple times throughout this project: every external dependency has its own constraints, and those constraints aren't always obvious until you run into them in production. Reading the documentation carefully before building is valuable. But some things only become real when the system is running against live data.
What the Final Dashboard Looks Like
The live display groups tracked stocks by their current stage: signal confirmed, breakout waiting, pullback in progress, and wave forming. Each confirmed signal card shows the key metrics from the moment it fired: the pullback depth as a percentage, the tick acceleration multiple, the signal grade, the exact time the signal was confirmed, and how much time has passed since then.
Stocks that have generated a secondary signal — a subsequent cross above the 120-period moving average — show an additional block with that signal's metrics: the number of times the cross has occurred, the current grade, and how trading value and trade intensity at the moment of the cross compared to the stock's baseline.
The display runs on a web app that's part of a broader regional platform I maintain. During market hours, the signal board is live and updating. After 15:30, the display clears and shows only the message that no new signals will be generated until the next session.
Today's Investing Insight — Why Real-Time Data Has Limits
Real-time market data sounds like perfect information, but it's worth understanding where the latency actually lives. From the moment a trade executes at the exchange to the moment it appears in your system, the data travels through the exchange's matching engine, the brokerage's data distribution system, your network connection, and your application's processing layer. Each step introduces a small delay. For most individual traders using a signal-based approach like this one, the total latency is typically in the range of tens to hundreds of milliseconds — not enough to matter for decisions that play out over minutes or hours. But it's a reminder that "real-time" is always an approximation, and any system built around speed should be honest about where in the chain its information actually comes from.
---
This post documents a personal journey of building an algorithmic trading system and is not a recommendation of any specific stock, strategy, or technology platform. Firebase and other third-party services have their own terms, pricing, and technical constraints that may change over time. All investment decisions and their outcomes are the sole responsibility of the investor.
Comments
Post a Comment