Copy Trading sounds simple: "When I buy, you buy." But when you scale this to 100 or 1,000 accounts, physics starts to get in the way.

If you loop through accounts one by one (Account A -> Account B -> Account C), the last account will execute seconds later than the first. In volatile markets, this means the Master makes a profit, and the last Child takes a loss. This is unacceptable.

The Pub/Sub Model

To solve this, we use a Publisher/Subscriber model, typically powered by Redis.

• The Master publishes a signal ("BUY NIFTY 18000 CE") to a channel.
• The Slaves (Workers) are all listening to this channel simultaneously.
• As soon as the message hits, 100 workers wake up instantly and fire orders to the broker API in parallel.

This reduces the "fan-out" latency from seconds to mere milliseconds.

Handling Partial Fills

What if the Master tries to buy 1000 quantity but only gets 500? Should the slaves trade?

Professional copy software logic dictates:

• Ratio Multiplier: Child Quantity = (Master Trade Size / Master Account Value) * Child Account Value.
• Fill Sync: Only replicate the quantity that was actually filled on the master, to ensure P&L alignment.

Cross-Broker Compatibility

The hardest part is mapping symbols across brokers. Zerodha calls it "NIFTY23JANFUT". Angel One calls it "NIFTY23JAN25FUT".

A robust copy engine needs a Symbol Master Map that standardizes these tickers in a central database, translating them on the fly for each destination broker.