A trading bot is four parts, and only one of them is the strategy

The first bot most people write is one file. It fetches a price, checks a condition, and sends an order. It works on a Tuesday afternoon and then something happens that it has no answer for: the API times out, a fill comes back partial, the position it thinks it has is not the position it actually has.

The fix is not more code in that one file. It is four separate pieces with clear jobs.

Data management

Getting prices, storing them, and knowing when they are stale. This piece owns the question "what does the market look like right now", and it has to answer honestly, including when the answer is "I do not know because the feed is down".

The rule is that the rest of the bot never calls the API directly. It asks this piece, and this piece decides whether to serve from cache, refetch, or refuse. Without that boundary you end up with rate limit errors appearing in your risk logic.

Signal generation

The strategy. Given the data, what position should we hold? This is the part everyone wants to work on, and it is the part with the fewest lines.

Its most important property is that it is pure: same data in, same target position out, no side effects. That way you can run it over history, unit test it, and reason about it. The moment your signal function also places orders, you can no longer test it without a broker.

Its output should be a target, not an instruction. "Be 30% long AAPL" rather than "buy 100 shares". The difference matters, because the target is comparable to what you already hold.

Risk management

Between the signal and the market. It takes the target position and decides whether it is allowed: position size limits, exposure limits, a maximum drawdown that halts trading, a check that you are not about to buy something you already hold too much of.

This is the piece that separates a bot you can leave running from one you have to watch. A signal with a bug is an inconvenience if risk limits catch it and a disaster if they do not exist. Write it before you go live, not after the first bad night.

Trade execution

Turning a target position into orders and confirming what actually happened. Reconciling what you asked for against what you got. Handling partial fills, rejections, retries, and the case where a request times out but the order went through anyway.

That last one is the one that bites. If you retry blindly on a timeout, you can double a position. Every order needs an identifier you can check against the broker before you resend.

Why the split pays

Each piece can be tested on its own. You can run the signal over history without a broker connection. You can test risk limits by feeding them positions that should be rejected. You can point execution at a paper account and confirm reconciliation works while the strategy is still garbage.

More importantly, when something goes wrong at three in the morning, the four parts tell you where to look. A single file tells you nothing.