Adding a second exchange without rewriting the first

The request usually arrives as “can it also trade Binance?”, and the answer depends entirely on a decision made months earlier: whether venue-specific behaviour was isolated or spread through the code.

The adapter boundary

One interface, implemented per venue. Everything above it speaks in normalised terms and never sees an exchange-specific field.

class Venue(Protocol):
    async def instruments(self) -> list[Instrument]: ...
    async def place(self, order: Order) -> OrderAck: ...
    async def cancel(self, order_id: str) -> None: ...
    async def positions(self) -> list[Position]: ...
    async def subscribe(self, topics: list[Topic]) -> AsyncIterator[Event]: ...

# Everything above this line is venue-agnostic.
# Everything below knows exactly one venue's quirks and nothing else.

The test for whether the boundary is real: can you write a strategy test that uses a fake venue and never imports anything exchange-specific? If not, the abstraction leaks and the second venue will be a rewrite.

What actually differs between venues

Each of these is a small thing that produces a subtle bug if it leaks upward. Quantity units are the classic: a bot that assumes base currency and meets a venue quoting contracts will place an order a hundred times too large, and it will do so successfully.

The instrument registry earns its place

One structure per tradable instrument, populated by the adapter, consumed by everything else. Venue, category, symbol as the venue spells it, canonical symbol as your system spells it, tick size, lot step, minimum quantity, minimum notional, contract multiplier, and what the quantity unit means.

Refresh it on a schedule. Venues change lot sizes and add instruments, and a registry cached at deployment eventually places orders that get rejected for reasons nobody can reproduce.

Risk is shared, or it is not risk

The most important consequence of multi-venue is not technical. If each venue has its own risk accounting, then a bot long BTC on one exchange and long BTC on another believes it holds two independent positions.

It holds one. Exposure, drawdown limits and correlation groups must be computed across the whole book, in one currency, at one moment. This is the same argument as in the risk engine, and multi-venue is where it stops being theoretical.

What not to build

• A universal order type. Support the intersection that actually exists. A synthetic type emulated differently per venue is a source of surprises.
• Cross-venue netting the exchanges do not do. Your model must match what the venues actually settle, not what would be convenient.
• Aggregated order books, unless you need them. A combined book across venues with different fees, latency and settlement is not a book you can trade against.
• Venue abstraction before the second venue exists. Build the first one cleanly, with the boundary in place. Generalise when you have two real cases, not one imagined one.

That last point is the practical one. A well-structured single-venue system takes days to extend. A prematurely generalised one takes weeks and encodes guesses about a venue nobody has integrated yet.