Trading infrastructure sizing: when you actually need co-location

A lot of trading infrastructure advice is really advertising for expensive hardware. Co-location, dedicated servers and low-latency everything sound serious, so they are easy to sell. The honest truth is that most strategies do not need any of it. Here is how to work out which side of that line you are on, before you spend money proving it the hard way.

The only question that matters: what does a delay cost you?

Every infrastructure decision comes back to one question. If your order went out a hundred milliseconds later, would it change the outcome? For a strategy that holds positions for hours or days, the answer is no, and no amount of expensive hardware will help it. For a strategy racing other people to the same fill, the answer is yes, and speed is the whole game. Almost everything else follows from where your strategy sits between those two.

Three honest tiers

Most systems fall into one of three bands, and each wants very different infrastructure.

• Light: positional, trend and fundamental. A few trades an hour, or a day. This runs happily on a small cloud instance, even across hundreds of tickers, for a few dollars a month. If someone is quoting you dedicated servers for a strategy like this, they are selling you something you do not need.
• Medium: intraday and scanners. Watching many symbols on tick or minute data, and acting through the day. This needs real compute and a fast, reliable data feed, but it still lives comfortably in the cloud. The cost goes into data and processing, not into shaving microseconds.
• Heavy: scalping, market making, some arbitrage. Here milliseconds decide the result, so low-latency, high-performance infrastructure is justified, and sometimes co-location next to the exchange. This is real, and where it applies we build for it properly. The point is that the workload justifies it, rather than the fear of missing out.

What co-location actually buys, and costs

Co-location means putting your server physically close to the exchange's systems, so your orders travel the shortest possible distance. For a latency-sensitive strategy that is a real edge. It also costs real money every month, adds operational complexity, and does nothing at all for a strategy whose edge is not speed. Buying it "to be safe" is like buying a race car to commute: expensive, and pointed at a problem you do not have.

The cloud default, and when to leave it

For most systems, ordinary cloud infrastructure is the right home. It is cheap, it is reliable, it resizes when your needs change, and it lets you spend your attention on the strategy rather than on managing hardware. You leave the cloud for two honest reasons: latency genuinely drives your edge, or you are moving so much data that a shared environment cannot keep up. If neither is true, staying in the cloud is not a compromise, it is the correct answer.

Where people waste money

The common mistakes all point the same way, toward paying for speed that does nothing. Renting a powerful dedicated server for a strategy that trades twice a day. Paying for co-location because a competitor mentioned it. Buying a premium tick data feed for a positional system that would be fine on the broker's own data. Each one is money leaving every month in exchange for a number that never touches your results. Sizing the infrastructure to the actual workload is how you avoid all of them.

Match the infrastructure to the workload

The skill is not building the biggest system. It is building the one your strategy actually needs, so it is fast enough where speed matters and cheap everywhere else. That is the whole idea behind our trading system architecture thinking, it shapes the execution engines we build, and it runs alongside the same honesty about market data, where the right answer is also usually cheaper than people expect.