Building a Trading Robot (Part 3): Execution Layer, Risk Management, and System Architecture
A trading advisor is not a thing by itself. And it is not a thing in a box that you can put on a shelf and forget. You have to run it, connect to it, request analysis, and then receive a signal. Once you say that out loud, the question becomes practical: what form will this product take for the user? There is a choice, but it is not unlimited. The most obvious option is to run a program on a personal computer: desktop or laptop, it does not really matter. The second option is a self-hosted setup, where you run the service on a rented machine on the Internet. And if we are greedy enough or entrepreneurial enough, pick what fits you better, we can build a full SaaS and sell trading signals as a service. If you reduce it to one simple checklist, all three options differ by answers to the same questions: where the advisor lives, who holds keys and data, who pays for infrastructure and tokens, and who is responsible when something breaks. Next we will go through each box and see which modules stay the same and which change sharply together with the delivery model. Desktop is the most direct and understandable option: the advisor lives on the user’s computer. Everything it knows and does stays nearby: settings, keys, candle history, cache, signals, logs. This immediately removes half of the anxiety about "where is my data" and "who else can see it". The upsides are obvious. First, everything is stored locally, without external infrastructure and extra intermediaries. Second, access to signals is fast: you open the app and see what is going on, without relying on your server. Third, this option is easier to extend later: you can add plugins for exchanges, models, news sources, and avoid turning the product into a monolith if the architecture allows it. But desktop has a price. Uptime is far from 100 percent: you close the laptop lid, the computer goes to sleep, the Internet drops, and the advisor "disappears". The data volume is also not small: OHLCV history grows quickly, then add analysis results, cache, logs, and later news. All of that lives on the user’s disk. Finally, the load is local too: CPU, memory, network, background tasks, and the more frequently you analyze the market, the more noticeable it becomes. Self-hosted is when you rent a server on the Internet, deploy the advisor there, and use it as a service. Deployment, config, keys, updates are on your side. Access is usually via the web, sometimes via an API, and the interface opens in a browser from any device. The advantages start with something simple: uptime is close to 100 percent. A server does not go to sleep and does not close its laptop lid. Then it gets more important: data sources are closer and more stable, fewer random network drops, it is easier to keep a cadence, and as a result signals are more consistent and predictable. Another practical plus is access from anywhere: you can connect from different devices and, if needed, grant access to trusted people without shipping the whole project or keys on a flash drive. The downsides are standard too. Infrastructure costs money, even if not a lot. Maintenance requires either skills or someone who covers them: updates, backups, logs, monitoring, basic "why did the process die". And there is a security angle: keys and data live on the server. Usually it is not a reason to panic, but the "install and forget" mode works worse here than in the desktop version. SaaS is not so much a delivery format as a business format. You do not "hand a box" to the user and ask them to deploy it. You run the infrastructure yourself and sell access by subscription: signals as a service. Implementation-wise it differs noticeably from self-hosted. There you have one server and one owner. Here you get users, roles, limits, data isolation, and everything that usually comes with it: billing, subscription accounting, cost control for tokens and load. Plus you need not only code, but people who will keep it running: monitoring, incidents, updates, customer support. At this point you are discussing processes, not just architecture. The reward is different too. SaaS is the level where the product starts living its own life: you can scale, ship changes quickly, accumulate statistics on signals, improve quality, and package it into clear plans. In other words, it is no longer an "advisor for yourself", but a platform with growth potential. There is no single correct box for an advisor. There is your goal, your usage mode, and your constraints. For one person desktop is more logical because everything is local and under control. For another self-hosted is better because they need stable uptime and access from different devices. And if you are thinking about a product and subscriptions, that is SaaS, with its own economics and organization. The choice should be based not on taste, but on plans and capabilities: how much time you are willing to spend on maintenance, who is responsible for uptime, where data and keys will live, and how you will grow if the project suddenly takes off. For additional technical explanations and common implementation questions, see the related Trading Automation FAQ section dedicated to this topic."Mine, all mine" - desktop version
"Let it sit here for now" - self-hosted service
"Fresh signals! Who wants signals?" - your own SaaS
Summary