Quant Bot Operations - Process Separation, Reporting, and Performance Tracking

The story of splitting a single monolithic script into several processes, and refining how reporting and performance tracking work along the way

This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).

There's something I care about almost as much as the quant bot's visible features — trade proposals, recommendation reports. Whether the system keeps running reliably when nobody's watching, and how I confirm it's actually running well. Here's where that stands.

Why I split it into multiple processes

At first, a single script did everything — computation, monitoring, reporting. The heavy ensemble computation kept fighting the five-minute-interval real-time monitor over resources.

So I split it into dedicated computation, monitoring, and reporting processes, with monitoring and reporting reading the computation results only through a disk cache.

On top of that, my dev environment crashed once a while back, and those processes quietly died along with it. So now the core processes are registered as OS-level services. Turning the dev environment off and on, or having it crash, no longer touches the actual trading and analysis processes.

Going a step further, I also pulled the trading-related background work that a single Telegram bot used to carry — cleaning up unfilled orders, logging start/end-of-day balances, checking safety mechanisms — out into its own separate process. The bot is now just a thin front door that receives and routes commands.

I learned a similar lesson on the networking side. After my home Wi-Fi sat half-broken for over half a day without anyone noticing, I built a separate monitoring program to detect and recover from network issues, as its own side project. I wrote that up in a separate post(new tab).

Splitting the reporting too

There used to be a separate scheduled report that scanned every stock at fixed times a few times a day, looking for unusual moves. I moved that responsibility over to the real-time monitor instead — catching anomalies the moment they happen beats waiting for a fixed check-in time.

I also split reporting itself into two tracks. The internal version I read myself carries everything needed to judge market conditions. The version meant for sharing with acquaintances is kept separate so that sensitive numbers like absolute amounts never appear in it at all.

I added a freshness indicator at the bottom of every report, showing how current the underlying data actually is. Data has quietly run stale for days at a time before without anyone noticing, so now a glance at the report is enough to catch that.

Keeping a running record of whether recommendations were right

I keep calculating and logging what the return would have been if I'd followed the AI's recommendations exactly. The principle is to refine features based on this record, not on a vague "feeling" after building something.

Recently I also added a separate gauge that measures the gap between the price at decision time and the actual fill price. The point is to separate the strategy's own performance from the losses that leak out during execution.

None of this is flashy, but it feels like these details are what eventually let you trust a system to run on its own. If you're curious about the overall project structure, check out the project architecture post(new tab) too.