Building a multi-bot architecture

When I first started building Oblivion, the architecture seemed obvious: one platform, one trading engine, one system responsible for everything.

At the time, this approach felt perfectly reasonable. After all, many trading applications operate this way. A single process receives market data, makes decisions and executes trades.

However, the more I worked on the project, the more limitations began to appear.

The problem with one big system

A single bot is easy to understand, easy to deploy and easy to visualize. But complexity grows surprisingly fast.

Managing one asset is relatively straightforward. Managing ten assets is not simply ten times harder. New questions begin to emerge.

How do positions interact? How should capital be distributed? What happens if one asset becomes extremely volatile while another remains inactive? How do you isolate failures?

As more responsibilities accumulated inside the same process, the architecture became increasingly difficult to reason about.

Isolation creates clarity

One realization changed the way I thought about the problem: what if every trading pair behaved like its own independent system?

Instead of one giant entity attempting to manage everything simultaneously, each market could have its own dedicated logic, state and lifecycle.

This idea immediately simplified many problems. A failure affecting one pair would not necessarily impact the others. Capital allocation became easier to understand, monitoring became more granular and debugging became significantly less painful.

Most importantly, the system became easier to scale.

Thinking in systems rather than trades

At some point I stopped thinking primarily about trades. Instead, I started thinking about systems.

A trade lasts minutes, hours or days. A system may operate for years.

The design decisions that matter most are rarely about a single position. They are about how the platform behaves after thousands of decisions have been made.

The architecture had to support that reality.

Complexity doesn't disappear

Building a multi-bot architecture does not eliminate complexity. It simply moves it.

Instead of managing complexity inside one giant process, you manage interactions between smaller components.

Coordination becomes important. Visibility becomes important. Consistency becomes important. The challenge shifts from execution to orchestration.

But this trade-off felt worthwhile.

Looking back

Today, I have difficulty imagining Oblivion built around a single monolithic trading bot.

The platform grew because the architecture allowed it to grow.

Features became easier to add. Failures became easier to isolate. The system became easier to reason about.

And perhaps most importantly, the architecture remained aligned with the original objective: building something capable of operating reliably over the long term.

The more time passes, the more convinced I become that architecture decisions often matter more than strategy decisions.

Good architecture doesn't guarantee success. But poor architecture eventually guarantees problems.