For a recommendation system, it's the recommendation logic. For an API, it's the business logic. For a data platform, it's the processing pipeline. For a trading system, it might be the strategy.

That's usually where the fun is.

We think about algorithms, performance, architecture, and new features. We build the happy path first, make it work, and then move on.

But after spending more time building software that depends on external systems, I've started to see the problem differently.

The hardest part often isn't making the system work.

It's making sure the system behaves correctly when reality doesn't.

A network connection disappears. An API request times out. A message arrives twice. Another message never arrives. Data becomes stale. A process crashes halfway through an operation. The application restarts and discovers that its local state doesn't match what actually happened.

These aren't unusual edge cases.

They're normal.

And this is where a simple application starts turning into a real system.

I've been exploring many of these problems while building CryptoBot, but the ideas aren't specific to trading. The same problems appear in payment systems, distributed applications, background workers, event-driven services, microservices, and almost anything that communicates with the outside world.

The Happy Path Is Easy

The first version of almost any system can look surprisingly simple:

Input
  ↓
Application
  ↓
External Service
  ↓
Response

The request arrives.

The application processes it.

The external service responds.

Everything continues.

That's the happy path.

And the happy path is usually not where the difficult engineering starts.

The interesting problems appear when one of our assumptions stops being true.

What happens if the external service doesn't respond?

What happens if the request reached the server, but the response was lost?

What happens if the application crashes immediately after the operation succeeds?

What happens if the same message is delivered twice?

What happens if the application believes something happened, but the external system says otherwise?

At that point, success and failure are no longer enough.

Sometimes the correct state is:

UNKNOWN

And that single state changes how you have to design the system.

A Timeout Doesn't Necessarily Mean Failure

Imagine an application sends a request to an external service.

The request leaves the application, but the connection disappears before the response arrives.

Eventually, the client reports:

TIMEOUT

What actually happened?

Maybe the request never reached the server.

Maybe the server is still processing it.

Maybe the server completed the operation.

Maybe the operation completed successfully, but the response was lost.

From the application's point of view, these situations can look almost identical.

That's why this assumption can be dangerous:

TIMEOUT = FAILED

A timeout really means something closer to:

"I didn't receive the response I expected."

That's a very different statement.

The operation might still have happened.

This becomes especially important when retries are involved.

Imagine the application does this:

Send Request
    ↓
  Timeout
    ↓
  Retry
    ↓
Send Request Again

If the first request actually succeeded, the second request could create a duplicate operation.

This is why reliable systems often need things like idempotency keys, unique request identifiers, retry limits, exponential backoff, and explicit operation states.

The important lesson isn't that retries are bad.

Retries are extremely useful.

The lesson is that you need to understand what happens when you retry.

Your Local State Is Not Reality

Another problem appears when an application maintains its own representation of an external system.

Imagine the application stores:

status = "completed"

It might have received that information from an API response, an event, a database, or another service.

But the application doesn't directly know reality.

It knows what it currently believes reality to be.

Usually that's good enough.

Until it isn't.

An event might be missed. A process might crash before saving an update. Messages might arrive out of order. Another service might change the state. A network connection might disappear at exactly the wrong moment.

Eventually you can have:

Local State
     ≠
Actual State

This is one of the fundamental problems of distributed software.

Your application can be internally consistent while still being wrong about the outside world.

This Is Why Reconciliation Matters

Reconciliation is simply the process of comparing what your application believes with what the external source of truth says.

Conceptually:

Local State
     ↓
   Compare
     ↓
External State
     ↓
  Mismatch?
   /     \
 No      Yes
 ↓        ↓

Continue Reconcile

This pattern is much more common than it might seem.

A payment system can reconcile transactions.

An inventory system can reconcile stock.

A cloud platform can reconcile infrastructure.

A trading system can reconcile orders and positions.

An event-driven application can compare its local state with a current snapshot.

The details are different, but the underlying problem is the same.

The application has an opinion about the current state.

Sometimes it needs to verify that opinion.

That's why I don't think reconciliation should be treated as a weird edge case.

For many systems, it's part of normal operation.

Events Are Fast. Snapshots Are a Safety Net.

Event-driven systems are powerful because applications can react to changes as they happen.

For example:

Created
  ↓
Updated
  ↓
Completed

This is great when every event arrives correctly.

But imagine the application receives Created and Updated, then loses its connection before Completed.

Now the local state is incomplete.

The application doesn't necessarily know that it missed something.

This is where snapshots become useful.

Events are great for keeping local state updated quickly.

Snapshots are useful for verifying or rebuilding that state.

A recovery flow might look like:

Events
  ↓
Local State
  ↓
Something Goes Wrong
  ↓
Fetch Current State
  ↓
Reconcile
  ↓
Correct Local State

This gives the system two mechanisms:

Fast updates during normal operation.

A way to recover when normal operation breaks.

That combination is much more robust than assuming every event will always arrive.

A Connected System Can Still Be Broken

One of the easiest mistakes is treating connectivity as a complete health check.

For example:

connected = true

Therefore:

system = healthy

Not necessarily.

The application can be connected while its data is stale.

It can be connected while an operation is still unknown.

It can be connected while its local state doesn't match the external system.

Connectivity tells you that a connection exists.

It doesn't tell you that the application is ready to make decisions.

That's why explicit application states can be much more useful.

For example:

STARTING
   ↓
CONNECTING
   ↓
SYNCING
   ↓
READY
   ↓
RUNNING

And if something goes wrong:

RUNNING
   ↓
DEGRADED
   ↓
RECOVERING
   ↓
SYNCING
   ↓
READY
   ↓
RUNNING

Now the application has a vocabulary for what is happening.

It's not simply "connected" or "disconnected."

It can be connected but not synchronized.

It can be running but degraded.

It can be recovering.

And importantly, it can know when it should not continue normal processing.

Sometimes the Correct Action Is to Stop

There is a natural tendency in automation to keep everything running.

Something fails?

Retry it.

The connection disappears?

Reconnect.

The request times out?

Send it again.

Sometimes that's correct.

Sometimes it's exactly the wrong thing to do.

Imagine the application discovers that its local state doesn't match the external system.

Continuing to process new operations might make the situation worse because every new decision is based on information the application no longer trusts.

A safer approach can be:

Mismatch Detected
      ↓
Stop Normal Processing
      ↓
Verify External State
      ↓
Reconcile
      ↓
Validate
      ↓
Resume

This is an important distinction.

The goal of reliability isn't:

"Keep the application running no matter what."

It's:

"Keep the application running when it is safe to do so."

Sometimes stopping is a successful recovery decision.

State Machines Are More Useful Than They Look

A lot of application logic starts with boolean flags.

You might have:

connected = true
processing = true
healthy = true
retrying = false

At first, this is simple.

As the application grows, however, more flags appear.

Eventually you can end up with combinations that don't make much sense:

connected = true
healthy = true
synchronized = false
processing = true

Should the system really be processing?

Explicit states make these situations easier to reason about.

For example:

CREATED
   ↓
PROCESSING
   ↓
COMPLETED

Or:

CREATED
   ↓
PROCESSING
   ↓
FAILED
   ↓
RECOVERING
   ↓
PROCESSING

Now the system has explicit transitions.

Instead of asking:

"Which combination of flags is currently true?"

You can ask:

"What state are we in, and what transitions are allowed from here?"

That's a much easier question to reason about.

Idempotency Changes How You Think About Failures

One of the most useful concepts for reliable systems is idempotency.

The idea is simple: performing the same operation multiple times should not accidentally create multiple side effects.

Imagine an application sends request #123.

The server processes it successfully.

But the response never reaches the client.

The client doesn't know what happened, so it tries again.

Without idempotency:

Request #123
     ↓
Resource Created

Request #123 Again
     ↓
Another Resource Created

With idempotency:

Request #123
     ↓
Resource Created

Request #123 Again
     ↓
Existing Result Returned

This doesn't solve every distributed-systems problem.

But it makes uncertain network behavior much easier to handle.

And uncertain network behavior is something we can't completely eliminate.

Recovery Should Be Designed From the Beginning

A common development process looks like this:

Build Feature
     ↓
Make It Work
     ↓
Add Error Handling
     ↓
Add Retries
     ↓
Deploy

The problem is that recovery often requires information that wasn't designed into the system in the first place.

If you don't store enough state, recovery becomes difficult.

If operations don't have unique identifiers, safe retries become harder.

If important transitions aren't observable, debugging becomes guesswork.

If there is no reliable source of truth, reconciliation may be impossible.

That's why I've started thinking about recovery at the same time as the normal workflow.

When designing a feature, ask two questions:

What happens when everything works?

How do we recover when it doesn't?

The second question often reveals more about the architecture than the first.

Observability Is Part of the System

Logs are often treated as something you add when debugging becomes painful.

I think they're more important than that.

When an application behaves unexpectedly, you need to understand not only what happened, but what the application believed was happening and why it made a particular decision.

For example:

RUNNING → RECOVERING
Connection restored
Synchronization started
State mismatch detected
State reconciled
RECOVERING → RUNNING

Now there is a story.

Without that context, you might only know that:

"The application stopped working."

Good observability should help answer three questions:

What happened?

What did the system believe happened?

Why did it make that decision?

This is especially important in asynchronous systems where there isn't always one place containing the complete history.

The Algorithm Is Only One Layer

This is probably the biggest change in how I think about software.

We often describe applications like this:

Input
  ↓
Algorithm
  ↓
Output

That's useful for explaining the core logic.

But it doesn't describe a production system.

A real application is usually closer to:

Input
  ↓
Validation
  ↓
Business Logic
  ↓
State
  ↓
External Systems
  ↓
Failure Handling
  ↓
Recovery
  ↓
Observability

The algorithm can be completely correct while the system still behaves incorrectly.

Not because the algorithm is bad.

Because the assumptions around it were wrong.

The input was stale.

The response was lost.

The state was outdated.

An operation was duplicated.

An event never arrived.

The process restarted at the wrong moment.

These aren't algorithm problems.

They're system problems.

What Building CryptoBot Taught Me

I've been exploring many of these ideas while building CryptoBot.

The project started around automated cryptocurrency trading, with market data, technical strategies, risk management, execution, backtesting, and exchange integrations.

But the more interesting engineering questions quickly moved beyond the strategy itself.

What happens when market data becomes stale?

What happens when an exchange connection disappears?

What happens when an order request times out?

What happens if the order actually succeeded?

What happens after a process restart?

What happens when local state doesn't match the external system?

These questions are useful even if you're not building trading software.

They are the same questions that eventually appear in almost any system that has to communicate with external services and operate without constant human supervision.

If you're interested in the project, you can find the source code here:

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

The Real Engineering Challenge

I don't think reliable software means preventing every possible failure.

That's impossible.

Networks will fail. Servers will restart. Dependencies will become unavailable. Messages will be delayed. External systems will behave unexpectedly.

The goal is to make those failures understandable and recoverable.

A reliable system should be able to recognize that something went wrong, determine what state it is in, verify what actually happened, recover its state, and only then continue.

Sometimes that means retrying.

Sometimes it means reconciling.

Sometimes it means rebuilding state.

And sometimes the safest decision is simply:

STOP
  ↓
RECOVER
  ↓
RECONCILE
  ↓
VALIDATE
  ↓
RESUME

That's the part of software engineering I find increasingly interesting.

Not just building systems that work.

Building systems that know when they don't.

And, more importantly, know what to do next.

Final Thought

The older I get in software engineering, the less impressed I am by systems that only work when everything goes perfectly.

The interesting systems are the ones that remain understandable when things go wrong.

A good algorithm matters. A clean architecture matters. Performance matters.

But so do the boring questions.

What if the response disappears?

What if the data is stale?

What if the same message arrives twice?

What if a message never arrives?

What if the process crashes halfway through an operation?

What if the local state is wrong?

What if we simply don't know what happened?

Those questions usually don't appear in the first version of a feature.

Eventually, they become part of the feature itself.

Maybe that's the real difference between software that works and software that can actually be trusted.

If you're building distributed systems, APIs, background workers, event-driven applications, or anything that depends on external services, I'd be interested to hear what failure case taught you the most.

For me, it was learning that "nothing crashed" doesn't necessarily mean "everything is okay."

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

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 trading results. The software does not guarantee profits. You are responsible for your own trading decisions, exchange accounts, API credentials, and financial risk.

At first, the architecture can be almost trivial:

Price → Strategy → Buy/Sell

That is enough to demonstrate an idea.

It isn't enough to build a reliable trading application.

Once the project needs real-time market data, multiple exchanges, automated execution, backtesting, risk controls, persistent state, logging and a usable Windows application, the problem changes completely.

You are no longer just writing a trading strategy.

You are building a small distributed system that happens to interact with financial markets.

I've been working on CryptoBot with that problem in mind. The project is a Windows-based automated cryptocurrency trading application built around strategy execution, market data, risk management and exchange connectivity.

Repository:

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

This article focuses on how I think about the architecture behind an automated trading system and some of the engineering problems that appear once the initial prototype starts becoming a real application.

The Core Pipeline

The simplest useful model for the system is:

                    Market Data
                         │
                         ▼
                  Data Processing
                         │
                         ▼
                     Strategy
                         │
                         ▼
                       Signal
                         │
                         ▼
                  Risk Management
                         │
                         ▼
                     Execution
                         │
                         ▼
                      Exchange

There are more components around this pipeline, but this is the part that matters most.

The key idea is that every stage has a different responsibility.

Market data provides information.

The strategy interprets that information.

Risk management decides whether the resulting action is acceptable.

Execution translates an approved decision into an exchange operation.

Keeping these responsibilities separate is much more valuable than trying to make the application "smart" in one giant module.

Market Data Comes First

A trading strategy is only as useful as the information it receives.

For different strategies, that information might include:

• current price;

• OHLCV candles;

• volume;

• order book data;

• account balances;

• open positions;

• historical market data.

There are two common ways an application can obtain this information from an exchange.

The first is request-based access through REST APIs.

The second is streaming data through WebSockets.

REST is convenient when the application needs to ask for something specific.

For example:

Get account balance
Get current order
Get historical candles
Submit order

WebSockets are more appropriate when the application needs a continuous stream of changing information.

The architecture then looks more like:

Exchange
   │
   │ WebSocket
   ▼
Market Data Handler
   │
   ▼
Internal Market State

That sounds simple until the connection breaks.

The Real Problem With WebSockets

A prototype often assumes that the connection remains alive.

Real networks don't work that way.

The connection can disappear.

The exchange can stop responding.

A message can be malformed.

Data can stop arriving without an obvious exception.

The application can reconnect but have incomplete local state.

This means a streaming component has to deal with more than receiving messages.

It needs to understand connection lifecycle.

A simplified lifecycle looks like:

CONNECT
   ↓
RECEIVE
   ↓
PROCESS
   ↓
DISCONNECT
   ↓
RECONNECT
   ↓
RESTORE STATE
   ↓
CONTINUE

The important part is the last two steps.

Reconnecting isn't necessarily enough.

The application also needs to know what happened while it was disconnected.

That is one of the first places where a trading application starts looking like a distributed system rather than a simple script.

Don't Let the Strategy Know About the Exchange

One of the architectural decisions that becomes important very quickly is keeping strategy logic independent from exchange-specific implementation.

Imagine a strategy that contains code like this:

if exchange == "binance":
    ...
elif exchange == "bybit":
    ...
elif exchange == "kraken":
    ...

It might work initially.

After several strategies and several exchanges, it becomes a maintenance problem.

Instead, the strategy should work with concepts such as:

price
volume
position
signal
order

The exchange adapter should deal with:

authentication
endpoints
request formats
exchange-specific parameters
responses
errors

Conceptually:

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

This separation makes the rest of the application considerably easier to evolve.

A Signal Is Not an Execution Command

This distinction is easy to miss.

Suppose a strategy determines that the current conditions match its entry rules.

It produces:

BUY BTC/USDT

That is a signal.

It should not necessarily mean:

SEND ORDER NOW

There can be another layer between them.

For example:

Strategy
   ↓
BUY signal
   ↓
Position check
   ↓
Risk check
   ↓
Position sizing
   ↓
Order creation
   ↓
Execution

This gives the application a place to enforce rules independently of the strategy.

That matters because strategies answer one question:

What would I like to do?

Risk management answers another:

Am I allowed to do it?

Those are not the same question.

Strategy Architecture

A strategy should ideally be replaceable without requiring changes throughout the application.

CryptoBot includes several categories of strategies, including technical analysis, trend following, scalping, arbitrage and machine-learning-based experimentation.

Technical analysis strategies can use familiar indicators such as:

• Moving Average;

• RSI;

• MACD;

• Bollinger Bands.

The important architectural property is that the strategy can consume market information and produce a consistent result.

For example:

Input
  ↓
Market State
  ↓
Strategy
  ↓
Signal

The rest of the system doesn't need to know whether that signal came from RSI, a moving-average crossover or a machine-learning model.

That is what makes a modular strategy system useful.

Why Backtesting Should Use the Same Strategy Logic

One of the things worth avoiding is maintaining completely separate implementations for live trading and backtesting.

If live trading uses one version of the strategy and the backtester uses another, the results become much harder to interpret.

A better model is:

                  Strategy
                 /        \
                /          \
       Historical Data    Live Data
              ↓                ↓
         Backtesting        Trading

The environment changes.

The strategy doesn't have to.

That makes it possible to test the same decision logic against historical data before exposing it to live execution.

Of course, a backtest still has limitations.

Historical execution isn't identical to live execution.

Real trading introduces:

• fees;

• spread;

• slippage;

• liquidity constraints;

• latency;

• partial fills;

• changing market conditions.

A good backtest can provide useful evidence.

It cannot turn historical performance into a guarantee about future results.

Risk Management Needs to Sit Between Strategy and Execution

Automated systems make risk controls especially important because software doesn't get bored or hesitate.

If a condition remains true, the program can continue acting on it.

That is why risk management should be explicit.

Common controls include:

Stop-loss
Take-profit
Trailing stop
Position sizing
Capital allocation

A useful mental model is:

                 Strategy
                    │
                    ▼
                  Signal
                    │
                    ▼
              Risk Engine
               /       \
              /         \
          REJECT       APPROVE
                         │
                         ▼
                      Order

A rejected signal is not necessarily a strategy failure.

The strategy may be correct about the market and the risk engine may still decide that the trade should not happen.

That separation is important.

Position Sizing Is More Important Than It Looks

A trading signal answers what direction a strategy wants.

It doesn't necessarily answer how much capital should be used.

Position sizing turns a decision into a quantity.

That means it belongs closer to the risk layer than the strategy itself.

For example, two strategies could generate the same signal:

BUY BTC

But the risk engine could calculate different position sizes depending on:

• available balance;

• configured risk;

• existing exposure;

• stop distance;

• portfolio allocation.

This keeps account-level risk rules consistent across different strategies.

Order Execution Is Its Own Layer

Once a signal passes risk checks, the system still needs to create and submit an order.

This is where exchange-specific details become important.

Different APIs can have different:

• authentication mechanisms;

• order parameters;

• symbol formats;

• response structures;

• error codes;

• rate limits;

• supported order types.

The execution layer translates the application's internal order representation into whatever the exchange expects.

Conceptually:

Internal Order
      ↓
Execution Adapter
      ↓
Exchange Request
      ↓
Exchange Response
      ↓
Internal Order State

This gives the rest of the application a stable interface even when the external API changes.

The Order Lifecycle

An order shouldn't be treated as a simple function call.

The application needs to understand that an order can exist in multiple states.

A simplified lifecycle might look like:

Created
   ↓
Submitted
   ↓
Accepted
   ↓
Partially Filled
   ↓
Filled

There are also other possible outcomes:

Rejected
Cancelled
Expired
Failed
Unknown

The Unknown state is particularly interesting.

Imagine:

1. The application submits an order.

2. The exchange receives it.

3. The network connection breaks.

4. The application doesn't receive the response.

The application cannot safely conclude that the order failed.

It may have succeeded.

This is one of those problems that doesn't appear in a basic trading-bot tutorial but becomes extremely important in real systems.

State Has to Survive Problems

An automated trading application needs to maintain some understanding of its current state.

For example:

Current balance
Open positions
Active orders
Selected strategy
Risk configuration
Connection state

If the application restarts, it shouldn't blindly assume that everything on the exchange disappeared with the process.

External state exists independently of the application.

This is why synchronization and reconciliation become important.

The application needs a way to compare what it thinks happened with what actually exists on the exchange.

Logging Is Part of the Trading System

Logging is sometimes treated as a debugging feature.

For automated trading, I think it's more than that.

Suppose the application opens a position and you later want to understand why.

You want to be able to reconstruct something like:

Market data received
↓
Strategy evaluated
↓
Signal generated
↓
Risk check passed
↓
Order created
↓
Order submitted
↓
Exchange response received
↓
Position updated

Without those events, investigating unexpected behaviour becomes difficult.

The dashboard tells you what is happening now.

Logs tell you what happened before.

Both are useful, but for different reasons.

Machine Learning Doesn't Replace the Trading Architecture

Machine learning is an interesting part of the project because it introduces another source of decisions.

A traditional strategy might be based on explicit rules.

A machine-learning system might instead produce a prediction.

For example:

Market Data
   ↓
Features
   ↓
Model
   ↓
Prediction
   ↓
Trading Decision

The prediction still has to pass through the same risk and execution layers.

That means:

Model
   ↓
Signal
   ↓
Risk Management
   ↓
Execution

This is important because a model should not have unrestricted access to the exchange simply because it produces a prediction.

Keeping the model separated from execution also makes experimentation easier.

You can change the model without rewriting the exchange layer.

Where Performance Actually Matters

Trading software naturally leads to discussions about performance.

Latency can matter.

CPU usage can matter.

Memory usage can matter.

But performance optimization should begin with measurement.

Suppose a calculation takes 5 milliseconds.

You could spend a lot of time rewriting it in C++ or assembly.

But if the application is waiting 100 milliseconds for an external operation, optimizing that 5-millisecond calculation may not produce a meaningful improvement.

The first question should always be:

Where is the bottleneck?

Profiling is much more useful than guessing.

Python, C++, C and Assembly

There is no reason to treat programming languages as mutually exclusive.

Python is useful for rapid development, data processing, experimentation and machine-learning workflows.

C and C++ provide more control when native performance or lower-level integration becomes important.

Assembly gives even more direct control over processor instructions.

But lower-level code is not automatically better.

The correct place for it depends on the workload.

If a calculation is genuinely CPU-bound, optimizing it can make sense.

If the application is dominated by network latency, assembly probably isn't going to solve the important problem.

That is why I prefer to optimize measured bottlenecks rather than optimize based on assumptions.

Windows Distribution Is Part of the Engineering

CryptoBot is intended to be used as a Windows application.

That means the project has concerns beyond source code.

The application needs to be packaged.

The executable needs a sensible version.

Configuration needs to be understandable.

Logs need to be accessible.

The release needs to be downloadable.

The application needs to start reliably.

These details aren't glamorous, but they are part of turning a development project into software that another person can actually use.

There is a significant difference between:

git clone
install dependencies
configure environment
run source code

and:

download
install
launch

The second experience requires additional engineering.

Security Is a Separate Concern

Trading software deals with credentials and potentially valuable accounts.

Exchange API keys should be treated as sensitive credentials.

A good baseline is to grant only the permissions that are actually required.

If withdrawals aren't required, withdrawal permissions should be disabled.

Credentials should never be committed into source control.

Wallet connections introduce another layer of responsibility.

A user should verify what the application is requesting before approving a connection or transaction.

Automation doesn't reduce the importance of security.

It increases it.

What Makes an Automated Trading System Difficult?

After working on the project, I'd describe the problem differently than I did when I started.

The hard part isn't calculating an indicator.

The hard part isn't sending a single API request.

The hard part is getting all the pieces to behave correctly together.

You need:

Reliable data
     +
Correct strategy logic
     +
Risk controls
     +
Reliable execution
     +
State management
     +
Error handling
     +
Observability

And those components have to keep working when the environment isn't behaving perfectly.

That's the real engineering problem.

A Useful Architecture Is One That Lets You Change Things

I don't think a good architecture is necessarily the one with the most abstractions.

It is the one that makes future changes less painful.

If adding a new strategy requires rewriting the exchange layer, something is too tightly coupled.

If supporting another exchange requires changing every strategy, the boundaries aren't clear enough.

If backtesting requires a second copy of the trading logic, the abstraction probably needs another look.

If changing the user interface requires touching execution code, the components aren't sufficiently separated.

The goal isn't architectural complexity.

The goal is controlled complexity.

What I'm Still Working On

CryptoBot is not something I consider "finished."

There are several areas where I want to keep improving the project.

Strategy development is one.

A trading system becomes much more useful when experimenting with a new idea doesn't require modifying unrelated parts of the application.

Backtesting is another.

The closer the testing environment can represent real execution conditions, the more useful the results become.

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

And there is still plenty to explore around machine learning and lower-level performance optimization.

Final Thoughts

The most useful lesson I've taken from building CryptoBot is that a trading bot isn't really a trading strategy.

The strategy is only one part.

The larger system looks more like:

                    ┌──────────────┐
                    │ Market Data  │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │   Strategy   │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │ Risk Engine  │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │  Execution   │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │   Exchange   │
                    └──────────────┘

Around that pipeline you need networking, state management, logging, configuration, testing and recovery.

That's where most of the engineering work lives.

The interesting part isn't making a program capable of placing one trade.

It's making a system that can continuously process information, make decisions, enforce its own constraints and communicate with external services without assuming that everything will always go according to plan.

That's the problem I'm interested in solving with CryptoBot.

The project is available here:

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