I Built a Multi-Broker Trading Platform — Here’s What Actually Broke (and How I Fixed It)

Most trading tools lock you into a single broker.

I didn’t like that.

So I started building a platform where you can connect multiple brokers and manage your trades from one place—positions, orders, execution logic, everything.

Sounds straightforward… until it isn’t.

This is not a “how to build a trading app” guide.

This is what actually went wrong while building one—and how I dealt with it.

💡 The Idea

The goal was simple:

• Connect multiple brokers (like IBKR, FYERS, ZERODHA etc.)

• Provide a unified interface for:

  • Positions
  • Orderbook
  • Order placement / cancellation / modification

• Add automation:

  • Auto-sell based on target/stop-loss

• Handle real-time data using WebSockets

Basically: one platform to control everything without juggling multiple apps.

Architecture (High-Level)

Backend:

• FastAPI
• WebSockets for real-time updates
• Broker-specific modules (client, orders, portfolio)

Frontend:

• React

Core idea:
Each broker has its own implementation, but the platform exposes a common interface.

So internally:

• Different logic
• Externally: same API

Challenge 1: Every Broker is… Different

This was the first reality check.

Even though brokers provide similar features:

• Authentication flows differ
• Order formats differ
• Response structures differ
• WebSocket behavior differs

What I did

Created a broker abstraction layer:

• client.py → authentication
• orders.py → order placement, cancel, modify
• portfolio.py → positions, holdings

Each broker implements the same structure.

So instead of:

if broker == "xyz":

I just do:

broker.place_order(...)

Clean. Scalable. Less headache later.

Challenge 2: Real-Time Execution Isn’t “Real-Time”

For features like:

• Stop-loss
• Target-based selling

You need live price updates.

Initially, I used WebSockets directly within the main application.

What broke?

• Random disconnects
• Delayed ticks
• Missed execution windows

And in trading, delay = money lost.

What I changed

I shifted this responsibility to an independent service.

Instead of handling execution inside the main app, I built a separate service that:

• Continuously monitors live prices
• Runs independently of the main backend
• Triggers sell execution when conditions are met

Why this worked better

• Isolation: Failures in price monitoring don’t affect the main system
• Reliability: Dedicated process for handling real-time logic
• Scalability: Easier to optimize and scale independently

Also learned:

Don’t blindly trust WebSocket streams. Always have a fallback.

Challenge 3: Order State Lies (Sometimes)

You place an order.

Broker says: “Placed.”

But actual state?

• Pending
• Partially filled
• Rejected later

Problem

Your system thinks:

“Done.”

Reality:

“Not even close.”

Solution

• Continuously sync order status
• Treat broker as source of truth

• Build logic for:

  • partial fills
  • retries
  • cancellations

Challenge 4: Automation is Harder Than It Sounds

“Auto-sell when target hits” sounds easy.

It’s not.

Issues faced:

• Price spikes triggering false execution
• Multiple triggers firing at once
• Race conditions

Fixes:

• Locking execution per position
• Adding thresholds (buffer zones)
• Validating before placing sell orders

What’s Next

• Add more brokers
• Improve execution latency
• Build better analytics around trades
• Scale infrastructure

Final Thoughts

Building this wasn’t just about coding.

It was about:

• handling uncertainty
• designing for failure
• and thinking beyond “happy paths”

If you're building anything involving real-time systems or external APIs:

Expect things to break. Design anyway.

If you’ve worked on something similar or are building in this space, I’d love to hear your experience.