What breaks first in automated trading systems

When people think about automated trading, they usually focus on one thing: the strategy.

Will it generate profits? Will it outperform the market? Will it survive different market conditions?

These are important questions, but after spending years building Oblivion, I've become convinced that they're rarely the first problems you'll encounter.

In practice, most automated trading systems don't fail because of their trading logic. They fail because of everything surrounding it.

The strategy is only one component

It's tempting to believe that once a strategy works, the difficult part is over. Unfortunately, that's only the beginning.

A trading platform depends on many moving parts working together.

Market data needs to arrive on time. Exchange APIs need to respond. Orders need to be acknowledged. Internal state needs to remain consistent. The application itself needs to continue running, sometimes for weeks without interruption.

None of these problems are directly related to trading, yet all of them determine whether the strategy can actually execute.

Small problems become big problems

One lesson I've learned is that seemingly insignificant issues rarely stay insignificant.

A temporary network interruption. A timeout that happens once every few thousand requests. A process that slowly consumes more memory than expected.

None of these events look particularly dangerous on their own. But software runs continuously.

A tiny issue repeated often enough eventually becomes a real operational problem.

The objective is therefore not only to solve obvious failures, but also to eliminate the accumulation of small ones.

Reality is messier than documentation

Every API comes with documentation. Every library has examples. Everything appears predictable while reading specifications.

Production environments quickly prove otherwise.

Unexpected responses happen. Temporary outages occur. External services behave differently than expected.

Sometimes nothing is technically wrong, yet the system still needs to make sensible decisions under imperfect conditions.

This is where engineering starts becoming more important than implementation.

Resilience is built, not added

One misconception I had early in the project was believing that resilience could be added later.

Build the features first. Make everything robust afterwards.

In reality, that approach rarely works.

Reliability is not a layer you place on top of an application. It emerges from hundreds of small architectural decisions made throughout the project.

How components communicate. How failures are detected. How recovery happens. How state is preserved.

These decisions quietly determine whether a platform remains dependable months after deployment.

Engineering changes your perspective

The longer I worked on Oblivion, the less I worried about whether a strategy could produce another trade.

Instead, I found myself asking different questions.

What happens if the exchange becomes unavailable? What happens if the application restarts unexpectedly? Can the platform recover automatically? Can it continue operating without human intervention?

Those questions rarely appear in discussions about trading.

Yet they often determine whether an automated system deserves to be trusted.

Looking back

Today, I no longer believe the first challenge of automated trading is finding a profitable strategy.

The first challenge is building a platform capable of executing that strategy reliably every single day.

Strategies evolve. Markets change. Ideas improve.

But reliability remains the foundation that allows every other improvement to exist.

Before worrying about optimizing a system, it first needs to be a system that can survive.