DEV Community: John Doe

I Thought the Hardest Part of a Trading Bot Was the Strategy

John Doe — Wed, 02 Sep 2026 11:02:39 +0000

When I started building CryptoBot, I thought the hardest part would be the trading strategy.

RSI, MACD, moving averages, momentum, backtesting...

That was the fun part.

But after spending more time on the project, I started running into a different kind of problem.

The strategy could be completely fine.

The software around it wasn't always fine.

A bot can generate a perfectly reasonable BUY signal and still make the wrong decision because the market data is stale, the exchange connection disappeared, or the application doesn't know whether an order was actually executed.

That's when I started looking at the project differently.

Instead of:

Strategy → Signal → Order

I started thinking about:

Market Data → Validation → Strategy → Risk Management → Execution → Exchange → Reconciliation → Recovery

The strategy is only one part of the system.

The Happy Path Is Easy

The basic flow of a trading bot is almost too simple:

┌──────────────┐
│ Market Data  │
└──────┬───────┘
       ↓
┌──────────────┐
│   Strategy   │
└──────┬───────┘
       ↓
┌──────────────┐
│ Risk Check   │
└──────┬───────┘
       ↓
┌──────────────┐
│    Order     │
└──────┬───────┘
       ↓
┌──────────────┐
│   Exchange   │
└──────────────┘

Everything works.

The data arrives.

The strategy runs.

The order is accepted.

The exchange responds.

Great.

But that's the happy path.

Real systems don't stay there for very long.

Eventually:

the WebSocket disconnects;
market data becomes stale;
an API request times out;
an order is partially filled;
the application crashes;
an event is missed;
local state doesn't match the exchange.

And this is where the interesting engineering starts.

A WebSocket Can Reconnect and Still Be Wrong

CryptoBot can use WebSockets for real-time market data.

Normally:

CONNECT
   ↓
RECEIVE DATA
   ↓
PROCESS DATA
   ↓
CONTINUE

Then something happens:

CONNECT
   ↓
RECEIVE DATA
   ↓
CONNECTION LOST

The obvious solution is to reconnect.

But reconnecting isn't the same as recovering.

Imagine the connection was down for ten seconds.

During those ten seconds:

the price may have changed;
an order may have been filled;
an order may have been cancelled;
multiple events may have happened.

The WebSocket reconnects.

But what did the bot miss?

That's the important question.

Connected
    ≠
Synchronized

A safer recovery flow looks more like:

Connection Lost
      ↓
   Reconnect
      ↓
  Synchronize
      ↓
 Validate State
      ↓
Resume Trading

The bot shouldn't necessarily start trading immediately after reconnecting.

It first needs to know what happened while it was disconnected.

Stale Data Is More Dangerous Than a Crash

A crash is easy to notice.

The process is dead.

Stale data is different.

The application can be running perfectly while making decisions using old information.

Imagine the last BTC update arrived 30 seconds ago.

The bot still has:

last_price = 105200

So the strategy runs.

Maybe it sees an entry condition.

Maybe it generates:

BUY BTC

But the market data is 30 seconds old.

The actual problem is not necessarily the strategy.

The strategy was given bad input.

A simple freshness check can prevent this:

MAX_DATA_AGE = 5

if time.time() - last_market_update > MAX_DATA_AGE:
    trading_enabled = False

The idea is simple:

          Market Data
               ↓
        Is data fresh?
           /      \
         YES       NO
          ↓         ↓
      Strategy     STOP
          ↓
        Trade

Sometimes the best decision a trading bot can make is:

I don't trust the data, so I'm not trading.

That's not a failure.

That's risk control.

The Worst Case: "Did My Order Happen?"

This is probably the failure mode I find most interesting.

Imagine:

Bot
 ↓
POST /order
 ↓
Exchange

The request is sent.

Then the network disappears.

No response.

Now the bot has a problem.

Did the exchange receive the order?

Maybe.

Did it accept it?

Maybe.

Did it execute it?

Maybe.

The bot doesn't know.

And that's very different from:

Order Failed

A timeout really means:

The client didn't receive a response.

It doesn't necessarily mean:

The exchange didn't process the request.

This is why blindly retrying can be dangerous.

For example:

Create Order
     ↓
   Timeout
     ↓
    Retry
     ↓
Create Order

If the first order actually succeeded, you may now have a duplicate.

A better approach is to treat the result as unknown:

┌─────────────────┐
│  Submit Order   │
└────────┬────────┘
         ↓
      Timeout
         ↓
┌─────────────────┐
│     UNKNOWN     │
└────────┬────────┘
         ↓
   Query Exchange
         ↓
  Determine State
         ↓
 Update Local State

This is one of those concepts that applies far beyond trading.

Whenever you communicate with an external system, there can be a difference between:

"It failed."

and:

"I don't know what happened."

Those are not the same thing.

An Order Is a State Machine

It's also tempting to think of an order as a simple function call:

order = create_order(...)

But in reality, an order has a lifecycle.

For example:

CREATED
   ↓
SUBMITTED
   ↓
ACCEPTED
   ↓
PARTIALLY_FILLED
   ↓
FILLED

It can also go another way:

CREATED
   ↓
REJECTED

Or:

ACCEPTED
   ↓
CANCELLED

Or even:

SUBMITTED
   ↓
UNKNOWN

Partial fills make things even more interesting.

Suppose the bot wants to buy 1.0 BTC.

The exchange might report:

0.2 BTC filled

Then:

0.5 BTC filled

And eventually:

1.0 BTC filled

If the bot misses one event, its local state can become incorrect.

The exchange may know that 0.5 BTC has been filled.

The bot may still think it's 0.2 BTC.

Now the rest of the system is operating on the wrong state.

Local State Is Not Reality

This is probably the most important thing I've learned while working on the project.

Imagine:

LOCAL STATE
BTC Position = 0.0

But the exchange says:

EXCHANGE STATE
BTC Position = 0.1

Which one is correct?

The exchange.

The local state is only the application's current understanding of reality.

It can become wrong because:

Missed Event
     ↓
Incorrect Local State

or:

Network Failure
     ↓
Incomplete State

or:

Application Restart
     ↓
State Must Be Rebuilt

This is why reconciliation matters.

┌───────────────┐
│    Exchange   │
│  Actual State │
└───────┬───────┘
        ↓
┌───────────────┐
│ Reconciliation│
└───────┬───────┘
        ↓
┌───────────────┐
│  Local State  │
└───────┬───────┘
        ↓
┌───────────────┐
│    Strategy   │
└───────────────┘

The goal isn't to eliminate every possible failure.

The goal is to have a way to recover from them.

WebSocket + REST

This is where WebSocket and REST APIs complement each other.

WebSocket is great for fast updates:

WebSocket
    ↓
Real-Time Events
    ↓
Local State

REST can provide a snapshot:

REST API
    ↓
Current State
    ↓
Reconciliation

Together:

WebSocket
    ↓
Fast Updates
    ↓
Something Goes Wrong
    ↓
REST Snapshot
    ↓
Reconciliation
    ↓
Correct State

This pattern is useful because events are fast, but snapshots are useful for recovery.

If the application missed something, it needs another way to find out what the current state actually is.

`connected = true` Is Not Enough

One of the simplest implementations would be:

if connected:
    trade()

But consider this:

WebSocket:       CONNECTED
Market Data:     STALE
Position:        UNKNOWN
Order State:     UNSYNCHRONIZED

Technically:

connected = True

But should the bot trade?

No.

This is why application state matters.

Instead of a single boolean, I prefer something closer to:

CONNECTING
    ↓
  SYNCING
    ↓
   READY
    ↓
  RUNNING

And if something goes wrong:

RUNNING
    ↓
RECOVERING
    ↓
  SYNCING
    ↓
   READY
    ↓
  RUNNING

There should also be a state where trading is explicitly blocked:

STATE MISMATCH
      ↓
STOP TRADING
      ↓
  RECONCILE
      ↓
   VALIDATE
      ↓
   RESUME

The goal isn't:

Keep the bot running no matter what.

It's:

Keep the bot running when it is safe to do so.

Risk Management Should Be Separate

The strategy might say:

BUY BTC

That doesn't automatically mean the order should be sent.

CryptoBot also includes risk-management concepts such as:

stop-loss;
take-profit;
trailing stops;
position sizing;
capital allocation;
portfolio rebalancing.

The basic idea is:

Strategy
   ↓
  BUY
   ↓
Risk Management
   ↓
 Allowed?
  /    \
YES     NO
 ↓       ↓

ORDER REJECT

I like this separation because the strategy answers:

What do I want to do?

While risk management answers:

Should I actually do it?

Those are different questions.

Backtesting Doesn't Test Reality

CryptoBot also supports backtesting.

That's useful for testing strategies against historical data:

Historical Data
       ↓
    Strategy
       ↓
Simulated Execution
       ↓
     Results

You can analyze things like:

profit and loss;
win rate;
drawdown;
number of trades;
trading costs;
strategy performance.

But there is something a backtest usually doesn't reproduce very well:

the ugly parts of reality.

A backtest doesn't randomly lose a WebSocket connection.

It doesn't receive half of an execution event.

It doesn't restart after an order was filled.

It doesn't have to wonder whether an API request timed out after the exchange accepted it.

So a strategy performing well in a backtest doesn't automatically mean the live trading system is reliable.

These are two different engineering problems.

This Changed How I Look at CryptoBot

When I started CryptoBot, I was mostly interested in strategies.

Now I'm just as interested in what happens around them.

The project includes:

automated cryptocurrency trading;
real-time market data;
technical-analysis strategies;
backtesting;
risk management;
automated execution;
multi-exchange support;
custom strategies;
stop-loss and take-profit;
trailing stops;
portfolio rebalancing;
performance analytics;
experimental machine-learning approaches.

But the questions I find most interesting are often simpler:

What happens when the connection disappears?

What happens when the data is stale?

What happens when the response disappears?

What happens when the order actually succeeded?

What happens when the application crashes?

What happens when the local state is wrong?

What happens when the bot simply doesn't know what happened?

These aren't strategy questions.

They're system questions.

And I think they're what separates a trading script from a trading system.

Final Thought

A trading bot isn't just:

Strategy → Order

It's more like:

Market Data
     ↓
  Validation
     ↓
   Strategy
     ↓
Risk Management
     ↓
  Execution
     ↓
   Exchange
     ↓
Reconciliation
     ↓
   Recovery

The strategy decides what the bot wants to do.

The rest of the system has to make sure the bot understands what is actually happening.

And sometimes the safest decision isn't:

BUY

or:

SELL

It's:

STOP
  ↓
RECOVER
  ↓
RECONCILE
  ↓
VALIDATE
  ↓
RESUME

That's probably the biggest lesson I've learned while building CryptoBot.

I'm not trying to build a bot that trades all the time.

I'm trying to build one that knows when it shouldn't trade.

If you're building a trading bot or another event-driven system, what's the failure mode you find hardest to handle?

Stale data?

Duplicate orders?

Lost events?

Exchange outages?

State reconciliation?

Or something completely different?

I'd be interested to hear about it.

CryptoBot

GitHub repository

CryptoBot is an ongoing project focused on cryptocurrency trading automation, algorithmic strategies, market analysis, backtesting, risk management, and experimentation with different approaches to automated trading.

Disclaimer: CryptoBot is provided for development, testing, research, and educational purposes. Cryptocurrency trading involves significant financial risk and can result in the loss of capital. Past backtesting results do not guarantee future performance or profits. The software does not guarantee profits.

The Software Isn't Broken — Your Assumptions Are

John Doe — Sun, 30 Aug 2026 14:32:54 +0000

Most software doesn't fail because the developer forgot how to write code.

It fails because the code was built around assumptions that eventually stopped being true.

We assume the network will respond.

We assume data will be fresh.

We assume a process will keep running.

We assume a database will always be available.

We assume an external API will behave exactly as documented.

We assume the state in our application represents the real state of the system.

Most of these assumptions are reasonable.

The problem is that software systems eventually encounter the situations where they aren't true.

And that's where reliability starts.

The Happy Path Creates False Confidence

Consider a simple API call:

Application
    ↓
API Request
    ↓
Response
    ↓
Process Data

It works.

You test it locally.

You deploy it.

Everything looks fine.

Then one day:

Application
    ↓
API Request
    ↓
Timeout

Now the application has a decision to make.

Should it retry?

Should it stop?

Was the request processed?

Is the local state still valid?

A single line of code suddenly becomes a system-design problem.

That's why the happy path is not enough.

A reliable system needs to define what happens when the expected sequence is interrupted.

A Timeout Doesn't Always Mean Failure

One of the most dangerous assumptions in distributed software is:

No response = operation failed

That isn't necessarily true.

Imagine an application sends a request:

Client
   |
   | request
   ↓
Server

The server processes it successfully.

But before the response reaches the client:

Server
   |
   | response
   X
Network failure

The client sees:

TIMEOUT

But the operation may already have happened.

If the client blindly retries, it may perform the same operation twice.

This is why reliable systems often need concepts such as:

idempotency;
request identifiers;
state reconciliation;
retries with limits;
explicit unknown states.

The important lesson is that communication failure and operation failure are not always the same thing.

Stale Data Is Still Data

Another dangerous assumption is that data is valid simply because it exists.

Imagine a service receives information from another system.

The last update arrived one minute ago.

The application still has a perfectly valid object in memory.

Nothing is technically broken.

But the information may now be useless.

Last Update
    ↓
Time Passes
    ↓
Local Data Remains
    ↓
Application Uses It

This is why systems that depend on real-time information often need freshness checks.

Instead of asking only:

Do I have data?

the application should sometimes ask:

How old is this data?

That small difference can completely change system behavior.

State Is Harder Than Functions

Developers naturally think in terms of functions:

fetch()
calculate()
save()
send()

But long-running systems are often easier to understand in terms of state.

For example:

STARTING
   ↓
CONNECTING
   ↓
READY
   ↓
RUNNING
   ↓
RECOVERING
   ↓
READY

Now failures become transitions rather than unexpected events.

For example:

RUNNING
   ↓
CONNECTION_LOST
   ↓
RECOVERING
   ↓
SYNCING
   ↓
RUNNING

This way of thinking is useful for many kinds of software:

background workers;
payment systems;
monitoring services;
distributed applications;
desktop applications;
data pipelines;
automated trading systems.

The exact states change.

The principle doesn't.

Recovery Is Different From Restarting

A common approach to failure is:

Something went wrong
        ↓
Restart application

Sometimes that works.

But restarting a process doesn't automatically restore the state that existed before the failure.

Imagine:

Application
    ↓
Operation started
    ↓
Process crashes

When the application starts again, it needs to know:

Did the operation finish?

Did it partially finish?

Is it still running?

Should it be retried?

Is the previous state trustworthy?

This is why recovery often requires synchronization with the external system.

A useful pattern is:

Restart
   ↓
Load Local State
   ↓
Query External State
   ↓
Compare
   ↓
Reconcile
   ↓
Resume

The application doesn't simply continue from where it thinks it stopped.

It verifies reality first.

External Systems Will Eventually Behave Differently

Even when an API is well designed, the surrounding environment can change.

A response can be delayed.

A field can be missing.

A rate limit can be reached.

Credentials can expire.

A service can temporarily become unavailable.

A dependency can return an unexpected error.

This doesn't mean that every possible failure needs hundreds of lines of defensive code.

It means important assumptions should be explicit.

For example:

if data is stale:
    stop processing

if dependency is unavailable:
    retry with backoff

if state is inconsistent:
    reconcile

if recovery fails repeatedly:
    stop and alert

The exact implementation depends on the application.

The important part is that the behavior is intentional.

Not Everything Should Be Retried

Retries are useful.

They are also easy to misuse.

A simple pattern looks like:

error
 ↓
retry
 ↓
error
 ↓
retry
 ↓
error
 ↓
retry

This can turn a small problem into a much bigger one.

For temporary network failures, a limited retry with backoff may be reasonable.

For an inconsistent financial transaction, blindly retrying may be dangerous.

For corrupted application state, retrying the same operation may accomplish nothing.

A reliable system should first ask:

What kind of failure is this?

Then choose the recovery strategy.

Sometimes the correct answer is retry.

Sometimes it is reconciliation.

Sometimes it is simply stopping.

Observability Changes Everything

When something fails in production, the question isn't only:

What exception happened?

A more useful question is:

What was the system doing when it happened?

Good logs can describe a sequence:

Request started
Dependency connected
Data received
Validation passed
Operation started
Timeout detected
State changed: RUNNING → RECOVERING
Reconciliation started
State restored
System resumed

This gives you a story.

Without that story, debugging becomes guesswork.

For long-running software, logging and monitoring aren't decorations added after development.

They are part of the architecture.

Reliability Is About Controlled Failure

Perfect software doesn't exist.

Networks fail.

Servers fail.

Processes crash.

Dependencies become unavailable.

Data becomes stale.

The goal isn't to prevent every failure.

The goal is to make failure predictable.

A reliable system should be able to answer:

What failed?

What state are we in?

Can we safely retry?

Do we need to reconcile?

Should we stop?

How do we know that recovery succeeded?

That's a much stronger design than simply adding more error handling.

What I Learned From Building Real Systems

Working on larger projects changed how I think about software.

The interesting part is often not the main algorithm.

It's everything surrounding it.

State.

Networking.

Retries.

Validation.

Recovery.

Logging.

Concurrency.

External dependencies.

A small function can be perfectly correct while the overall system is still unreliable.

The difficult engineering work begins when you ask:

What happens when my assumptions are wrong?

That's the question that turns a prototype into a real system.

I've been exploring these ideas while building different parts of CryptoBot, where external APIs, real-time data, execution state, and recovery all have to work together.

The project is available here:

https://github.com/pavloaser23/crypto-trading-bot

Final Thought

The software usually isn't broken when the unexpected happens.

The unexpected situation is often exactly what the software should have been designed to handle.

The real problem is the assumption that everything will continue working exactly as it did during the first successful test.

Good engineering starts when we stop designing only for:

everything works

and start designing for:

something will eventually go wrong

Because it will.

The question is whether the system knows what to do next.

The Hardest Part of a Trading Bot Isn't the Strategy

John Doe — Sun, 30 Aug 2026 14:27:17 +0000

A trading strategy is usually the most visible part of an automated trading system.

You can see the indicators, the entry conditions, the signal, and eventually the order.

But after working on CryptoBot, I've started to think that the strategy is actually one of the easier parts.

The difficult part is everything that happens when reality doesn't behave as expected.

What happens when the WebSocket disconnects?

What happens when market data becomes stale?

What happens when an order is submitted but the response is lost?

What happens when the application restarts and its local state no longer matches the exchange?

These aren't unusual edge cases.

They are normal problems in a long-running distributed system.

The Happy Path Is Easy

A simple trading bot can be represented like this:

Market Data
    ↓
Strategy
    ↓
Signal
    ↓
Risk Check
    ↓
Order
    ↓
Exchange

Everything works.

The exchange responds, the network stays connected, market data arrives, and the order is accepted.

For a prototype, this is enough.

For software that should run continuously, it isn't.

Eventually something will fail.

The important question is not whether the system will fail.

The important question is what it will do when it does.

Reconnecting Isn't Recovery

Real-time market data is often delivered through WebSockets.

A connection can disappear because of network problems, exchange maintenance, server-side disconnects, or client-side failures.

A naive system does:

connect
receive data
process data
repeat

A more realistic system needs:

connect
    ↓
receive data
    ↓
connection fails
    ↓
detect failure
    ↓
reconnect
    ↓
restore state
    ↓
validate data
    ↓
continue

The important difference is the recovery step.

Suppose the connection was down for five seconds.

The bot reconnects successfully.

But what happened during those five seconds?

It may have missed market updates or order events.

Simply reconnecting doesn't restore the state that was lost.

The application may need to synchronize with the exchange before trading again.

Stale Data Can Be Worse

A disconnected connection is easy to detect.

Stale data is harder.

Imagine the application is still running, but the last market update arrived thirty seconds ago.

The strategy still has a price.

It's just an old price.

That creates a dangerous situation:

Market Data Stops
      ↓
Local State Remains Unchanged
      ↓
Strategy Keeps Running
      ↓
Signal Generated
      ↓
Order Submitted

A safer approach is to make data freshness part of the decision.

Market Data
    ↓
Freshness Check
    ↓
Fresh?
  /   \
Yes    No
 ↓      ↓
Trade   Stop

Sometimes the correct trading decision is simply:

I don't have reliable data, so I am not going to trade.

The Hardest Case: An Unknown Order

Consider a simple order request:

POST /order

The application sends it.

Then the network connection disappears.

No response arrives.

Did the exchange receive the order?

Maybe.

Did it execute?

Maybe.

The application cannot know from the timeout alone.

This is why:

timeout = failure

is dangerous.

The real state may be:

UNKNOWN

Blindly retrying can create a duplicate order if the first request actually succeeded.

A safer flow is:

Order Request
    ↓
Timeout
    ↓
UNKNOWN
    ↓
Query Exchange
    ↓
Determine Actual State
    ↓
Update Local State

This is one of the reasons an order should be treated as a state machine rather than just a function call.

An Order Has a Lifecycle

A simplified lifecycle can look like:

Created
   ↓
Submitted
   ↓
Accepted
   ↓
Partially Filled
   ↓
Filled

There can also be rejected, cancelled, expired, failed, or unknown states.

Partial fills make this even more interesting.

An order for 1.0 BTC might first be filled for 0.2 BTC, then 0.5 BTC, and finally 1.0 BTC.

If the application disconnects between those events, its local state may become inaccurate.

That's why reconciliation matters.

Local State Is Not Reality

The bot might have:

Local:
BTC position = 0.0

while the exchange has:

Exchange:
BTC position = 0.1

The local state is wrong.

The exchange is the system that actually holds the account and executes the trade.

This means the application needs a way to verify and rebuild its state.

A useful model is:

Exchange
    ↓
External State
    ↓
Reconciliation
    ↓
Local State
    ↓
Strategy

WebSocket events provide fast updates.

REST APIs can provide snapshots and help verify state.

One gives responsiveness.

The other provides a way to recover when events are missed.

Application Restarts Matter Too

Imagine:

Bot Running
    ↓
Order Submitted
    ↓
Order Filled
    ↓
Application Crashes

When the application starts again, it needs to know:

What positions do I have?
Which orders are still open?
Which orders were filled?
What happened while the bot was offline?

This is why startup recovery matters.

Instead of immediately starting to trade:

Application Start
       ↓
Query Exchange
       ↓
Compare State
       ↓
Reconcile
       ↓
Validate
       ↓
Start Trading

The bot should not assume that its previous local state is correct just because it was saved.

Recovery Should Be a Real State

A simple:

connected = true

isn't enough.

The system can be connected while still having stale or inconsistent state.

A better model is:

CONNECTING
    ↓
SYNCING
    ↓
READY
    ↓
RUNNING
    ↓
RECOVERING
    ↓
SYNCING
    ↓
RUNNING

There should also be a state where the bot refuses to trade.

For example, if the local position doesn't match the exchange position:

Mismatch Detected
      ↓
Stop Trading
      ↓
Reconcile
      ↓
Restore Consistency
      ↓
Resume Only If Safe

Not every error should automatically result in another retry.

Sometimes stopping is the correct behavior.

Logging Is Part of Reliability

When an automated system makes a decision, you should be able to understand why.

A useful log trail might look like:

Market data received
    ↓
Strategy evaluated
    ↓
Signal generated
    ↓
Risk check passed
    ↓
Order submitted
    ↓
Exchange response received
    ↓
Order filled

During recovery, state transitions are equally important:

WebSocket disconnected
RUNNING → RECOVERING
Reconnect successful
State synchronized
Market data refreshed
RECOVERING → RUNNING

If something happens at 3 AM while nobody is watching, the logs should make it possible to reconstruct what the bot believed and what it did.

Final Thoughts

When I started CryptoBot, I was mainly interested in automating trading strategies.

Over time, the more interesting questions became different:

What if the connection disappears?

What if the response disappears?

What if the data becomes stale?

What if the application restarts?

What if the local state is wrong?

What if an order exists but the bot doesn't know about it?

Those questions don't make the trading strategy smarter.

They make the software more reliable.

A real trading bot isn't just:

Strategy → Order

It is closer to:

Market Data
     ↓
Strategy
     ↓
Risk Management
     ↓
Execution
     ↓
Exchange
     ↓
Reconciliation
     ↓
Recovery

The hardest part isn't making the bot do something.

It's making sure that when something goes wrong, the bot knows enough to stop, recover, reconcile, and continue safely.

That's the part of CryptoBot I find most interesting.

https://github.com/pavloaser23/crypto-trading-bot

Inside a Crypto Trading Bot: What Actually Happens Between Market Data and an Order

John Doe — Sat, 29 Aug 2026 12:24:36 +0000

A cryptocurrency trading bot looks deceptively simple from the outside.

There is a market, there is some trading logic, and eventually an order gets sent to an exchange.

That description leaves out almost everything that makes the software interesting.

A real automated trading system has to continuously receive information, turn that information into something a strategy can understand, make a decision, check whether that decision is allowed, execute it through an external API, keep track of what happened, and recover when one of those pieces stops behaving normally.

I've been working on CryptoBot around exactly this problem.

The project started as an attempt to automate trading strategies and gradually grew into a much larger software engineering exercise. The more functionality I added, the more obvious it became that the trading strategy itself was only one small part of the system.

The project is available on GitHub:

https://github.com/pavloaser23/crypto-trading-bot

This article is about the engineering side of that problem.

Start With the Data

Every automated trading decision begins with information.

Depending on the strategy, that might include price, volume, candles, order book information, account state, or other market data.

The first architectural mistake is to let the strategy become responsible for acquiring all of it.

It is convenient initially.

You can write something like:

price = exchange.get_price("BTC/USDT")
signal = strategy.calculate(price)

if signal == "BUY":
    exchange.buy(...)

There isn't anything inherently wrong with this for a prototype.

The problem appears when the application grows.

Now the strategy knows about the exchange.

The exchange knows about the strategy.

The trading logic knows about networking.

Testing requires a live API.

And eventually even a small change can affect several unrelated parts of the application.

I prefer to think about the data flow as separate stages:

Market Data
    ↓
Data Processing
    ↓
Strategy
    ↓
Signal
    ↓
Risk Management
    ↓
Execution
    ↓
Exchange

The exact implementation can change, but keeping those responsibilities conceptually separate makes the system much easier to work on.

Market Data Has Its Own Problems

Market data sounds simple until you need it continuously.

A program can request a price periodically through a REST API. That works for many basic use cases.

A real-time application may instead use a WebSocket connection and continuously receive updates.

That introduces another category of problems.

Connections can disappear.

Messages can arrive unexpectedly.

The network can become unstable.

The exchange can temporarily stop responding.

Data can become stale.

The application needs to know whether it is still receiving valid information.

A simple implementation assumes this:

connect
receive data
process data
repeat

A production-oriented system has to consider something closer to:

connect
    ↓
receive data
    ↓
process data
    ↓
connection fails
    ↓
detect failure
    ↓
reconnect
    ↓
restore state
    ↓
continue

The difference between these two diagrams is where a lot of the engineering work lives.

Why REST and WebSocket Are Different Problems

REST APIs are request-oriented.

The application asks for something and receives a response.

That makes them convenient for operations such as retrieving account information, requesting historical information, or performing specific API operations.

WebSockets are different.

Instead of repeatedly asking for information, the application maintains a connection and receives events or updates.

That makes streaming data useful for applications that need to react to changing market conditions.

But persistent connections create their own responsibilities.

The application has to understand connection state.

It has to detect disconnects.

It needs a reconnect strategy.

It needs to decide what happens to data received around the time of a disconnect.

It may also need to rebuild part of its local state after reconnecting.

This is not really a "crypto problem."

It is a distributed-systems problem that happens to exist inside a trading application.

A Strategy Should Produce a Decision

Once market data has been processed, the strategy can evaluate it.

CryptoBot is designed around several common approaches, including technical analysis, trend following, scalping, arbitrage, and experiments involving machine learning.

A technical strategy might use indicators such as:

Moving averages
RSI
MACD
Bollinger Bands

The important architectural point isn't which indicator is used.

It's what the strategy produces.

Ideally, it produces a signal or decision rather than directly manipulating the exchange.

For example:

market data
    ↓
strategy
    ↓
BUY

That is much easier to work with than a strategy that immediately performs:

strategy
    ↓
authenticate with exchange
    ↓
construct request
    ↓
send order

The first design gives the rest of the system an opportunity to evaluate the decision.

A Signal Is Not an Order

This is one of the most important distinctions in an automated trading system.

Suppose a strategy produces:

BUY BTC/USDT

There is still no reason to assume that the system should immediately execute the trade.

The application may have risk limits.

There may already be an open position.

The requested position size may be too large.

The current configuration may prohibit the trade.

There may be insufficient available capital.

So the flow becomes:

Strategy
    ↓
Signal
    ↓
Risk Check
    ↓
Order

This makes risk management a separate responsibility rather than something hidden inside individual strategies.

Risk Management Is a System Component

Automated trading makes explicit risk rules more important, not less.

A human trader can decide not to take a trade.

Software will generally continue following its rules until something stops it.

CryptoBot includes controls such as stop-loss, take-profit, trailing stops, position sizing, and capital allocation.

The goal isn't to eliminate risk.

That isn't possible.

The goal is to make the rules explicit and enforceable.

For example, a strategy can say:

This looks like an entry.

The risk engine can then ask:

Is this position size allowed?
Is the account already exposed?
Are the configured limits satisfied?

Only after those checks should execution become possible.

This separation also makes strategy development safer because strategy code doesn't have to contain every account-level restriction.

Exchange Integration Is a Separate Engineering Problem

Supporting one exchange can be relatively straightforward.

Supporting several exposes the architectural differences much more clearly.

CryptoBot is designed around connections to centralized exchanges as well as Web3 wallet connections.

Exchange integrations can differ in authentication, endpoints, order formats, supported operations, rate limits, and error responses.

If those differences leak into the strategy layer, the strategy eventually becomes full of exchange-specific conditions.

That is the kind of coupling that becomes expensive later.

A cleaner model is:

                 Strategy
                    │
                    ▼
              Trading Signal
                    │
                    ▼
               Order Model
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Exchange   Exchange   Exchange
          A         B         C

The strategy works with trading concepts.

The integration handles the details of the particular exchange.

This makes adding or changing integrations much less disruptive.

The Order Lifecycle Matters

Another mistake is treating an order as a single function call.

In a real system, an order has state.

A simplified lifecycle might look like:

Created
   ↓
Submitted
   ↓
Accepted
   ↓
Partially Filled
   ↓
Filled

There can also be rejected, cancelled, expired, or failed states.

The particularly difficult case is when the application doesn't know what happened.

Imagine the application sends an order request and then the network connection disappears.

No response arrives.

That does not necessarily mean that the exchange didn't receive the order.

The request could have reached the exchange successfully while the response was lost.

This is why automated trading software has to think about state and reconciliation, not just function calls.

Reliability Is More Important Than the Happy Path

Most prototypes are designed around successful execution.

The application connects.

The API responds.

The strategy produces a valid signal.

The order succeeds.

That's useful for proving that the idea works.

It isn't enough for long-running automation.

A useful system needs to consider failures such as:

exchange downtime;
network interruptions;
invalid configuration;
expired credentials;
API rate limits;
malformed responses;
unexpected order states;
application restarts;
missing market data.

None of these are particularly interesting when you're writing the first version.

They become extremely interesting when the application has been running for hours.

Logging Is Part of the Architecture

When an automated system makes a decision, you should be able to understand why.

If something unexpected happens, logs are often the only way to reconstruct the sequence of events.

A useful log trail might tell you:

market data received
→ strategy evaluated
→ signal generated
→ risk check performed
→ order submitted
→ exchange response received

Without that information, debugging becomes guesswork.

This is especially important when the system is automated.

If a human clicks a button, there is usually a clear action associated with the event.

If a strategy makes a decision at 3:17 AM while nobody is watching, the software needs to leave enough information behind to explain itself.

Backtesting Changes the Data Source, Not the Strategy

Backtesting is another area where architecture matters.

Ideally, a strategy shouldn't need to know whether its input came from a live exchange or historical data.

Conceptually:

                   Strategy
                  /        \
                 /          \
        Historical Data    Live Data
              ↓                ↓
          Backtester        Exchange

The strategy receives data.

The environment determines where that data came from and how execution is handled.

This makes experimentation considerably easier.

You can evaluate an idea against historical data without modifying the strategy just because the execution environment changed.

But there is an important limitation.

A backtest is not a reproduction of reality.

Historical results can differ from live execution because of fees, spread, slippage, liquidity, latency, partial fills, and changing market conditions.

There is also a statistical problem.

If you repeatedly adjust a strategy until it performs extremely well on the same historical dataset, you can end up fitting the strategy to the past.

That is not the same as discovering a robust strategy.

Machine Learning Adds Another Layer

Machine learning is attractive in trading because markets generate a large amount of data.

A model can be used for prediction, classification, pattern recognition, or adaptive strategies.

But introducing machine learning doesn't remove the rest of the architecture.

The model still needs:

input data;
preprocessing;
feature generation;
inference;
validation;
output handling;
monitoring.

And a model prediction still needs to become a decision inside the larger system.

For example:

Market Data
    ↓
Features
    ↓
Model
    ↓
Prediction
    ↓
Strategy Decision
    ↓
Risk Check
    ↓
Execution

The machine-learning component is another part of the pipeline.

It isn't the pipeline itself.

Performance Needs Measurement

Trading software naturally leads to performance discussions.

Latency matters.

CPU usage matters.

Memory usage matters.

Concurrency matters.

But performance optimization without measurement can easily become wasted effort.

Suppose a particular calculation takes a meaningful amount of CPU time.

Optimizing that calculation may be worthwhile.

But if the application spends most of its time waiting for an external exchange API, making the calculation ten times faster may have almost no effect on the end-to-end latency.

That is why I prefer to start with profiling and measurements.

Find the actual bottleneck.

Then decide whether optimization is necessary.

Where C, C++ or Assembly Make Sense

Lower-level languages are interesting when a workload actually requires them.

C and C++ can provide more control over memory, execution and native integration.

Assembly can provide even more direct control over specific CPU operations.

But none of that automatically makes a trading system faster.

If the bottleneck is network latency, rewriting a piece of application logic in assembly won't make the exchange respond faster.

If the bottleneck is a CPU-heavy calculation performed millions of times, native optimization could make much more sense.

The important question isn't:

Can this be written in assembly?

It is:

Is this actually the part of the system that needs to be optimized?

That distinction prevents a lot of unnecessary complexity.

Why I Chose a Windows Application

Crypto trading software is often presented as a server or command-line application.

I wanted CryptoBot to be usable as a Windows application.

That changes the project considerably.

Now the software also has to deal with packaging, installation, configuration, executable distribution, logging locations, application startup and release management.

For a developer, running source code locally is easy.

For someone using a compiled application, the experience should be much simpler.

The user shouldn't have to understand the internal architecture just to launch the application.

That makes packaging and documentation part of the engineering work rather than something added at the very end.

Security Changes When the Software Can Trade

A program that can interact with a trading account needs to treat credentials seriously.

API keys should be protected.

Only required permissions should be enabled.

Withdrawal permissions should be disabled when they aren't necessary.

Credentials should never be committed to source control.

The same principle applies to wallet connections.

Users should understand what they're connecting and what they're authorizing.

This is another area where a trading application differs from a normal hobby script.

The software isn't just processing information.

It can potentially cause financial actions.

That raises the cost of mistakes.

The Most Difficult Part Isn't the Algorithm

After spending a lot of time working on this project, I think this is the part that is easiest to underestimate.

The algorithm is visible.

You can see the formula.

You can see the strategy.

You can see the signal.

The infrastructure around it is less visible.

Networking.

State.

Error handling.

Execution.

Risk.

Logging.

Recovery.

Configuration.

Testing.

Those pieces aren't as interesting in screenshots, but they're what determine whether the application behaves predictably.

A trading strategy can be mathematically simple.

Building software that executes it reliably is not.

What I Would Focus on Next

There are several areas of CryptoBot that I want to continue improving.

The first is making strategy development easier.

The second is improving the backtesting environment so that experiments can be performed more systematically.

Exchange connectivity and execution reliability are also areas that naturally require continuous work.

There is also plenty of room for performance improvements once actual bottlenecks become clear.

And machine learning remains an interesting area for experimentation, particularly when treated as one component of a larger system rather than as a replacement for the entire strategy architecture.

Final Thoughts

Building an automated crypto trading system changed my understanding of what a trading bot actually is.

It isn't just an algorithm.

It isn't just an exchange API.

It isn't just a dashboard.

It is a collection of systems that have to cooperate:

Market Data
     ↓
Strategy
     ↓
Risk Management
     ↓
Execution
     ↓
Exchange

Around that core, there is another layer responsible for reliability, state, logging, configuration, testing and recovery.

That's where most of the interesting engineering happens.

The project started with the idea of automating trading strategies.

It became an exercise in designing software that can operate continuously while the environment around it keeps changing.

That's the part I find most interesting.

CryptoBot is available on GitHub:

https://github.com/pavloaser23/crypto-trading-bot

DEV Community: John Doe

I Thought the Hardest Part of a Trading Bot Was the Strategy

The Happy Path Is Easy

A WebSocket Can Reconnect and Still Be Wrong

Stale Data Is More Dangerous Than a Crash

The Worst Case: "Did My Order Happen?"

An Order Is a State Machine

Local State Is Not Reality

WebSocket + REST

connected = true Is Not Enough

Risk Management Should Be Separate

Backtesting Doesn't Test Reality

This Changed How I Look at CryptoBot

Final Thought

CryptoBot

The Software Isn't Broken — Your Assumptions Are

The Happy Path Creates False Confidence

A Timeout Doesn't Always Mean Failure

Stale Data Is Still Data

State Is Harder Than Functions

Recovery Is Different From Restarting

External Systems Will Eventually Behave Differently

Not Everything Should Be Retried

Observability Changes Everything

Reliability Is About Controlled Failure

What I Learned From Building Real Systems

Final Thought

The Hardest Part of a Trading Bot Isn't the Strategy

The Happy Path Is Easy

Reconnecting Isn't Recovery

Stale Data Can Be Worse

The Hardest Case: An Unknown Order

An Order Has a Lifecycle

Local State Is Not Reality

Application Restarts Matter Too

Recovery Should Be a Real State

Logging Is Part of Reliability

Final Thoughts

Inside a Crypto Trading Bot: What Actually Happens Between Market Data and an Order

Start With the Data

Market Data Has Its Own Problems

Why REST and WebSocket Are Different Problems

A Strategy Should Produce a Decision

A Signal Is Not an Order

Risk Management Is a System Component

Exchange Integration Is a Separate Engineering Problem

The Order Lifecycle Matters

Reliability Is More Important Than the Happy Path

Logging Is Part of the Architecture

Backtesting Changes the Data Source, Not the Strategy

Machine Learning Adds Another Layer

Performance Needs Measurement

Where C, C++ or Assembly Make Sense

Why I Chose a Windows Application

Security Changes When the Software Can Trade

The Most Difficult Part Isn't the Algorithm

What I Would Focus on Next

Final Thoughts

`connected = true` Is Not Enough