Hot path, cold path: latency where it pays, reliability where it counts

A trading system has two jobs that pull against each other. One is to be fast — to get an order in front of the market before the opportunity evaporates. The other is to be correct — to write down what happened so durably that the system always knows the truth, no matter what fell over. You can't fully optimize for both in the same stretch of code. So you stop trying, and you split them: a hot path built for latency, a cold path built for reliability.

Most of the fragile systems I've seen got that way because nobody was willing to pick. They asked the order path to also be the system of record, and what came out the other end wasn't fast enough to win and wasn't durable enough to lean on. The whole discipline here is just deciding, out loud, which path a given piece of work lives on — and then refusing to let one path's needs quietly rot the other.

Two paths, two contracts

This isn't just fast code over here and slow code over there. The two paths make different promises, and they're built to be afraid of different things.

• The hot path carries the order from decision to venue. Its job is speed. Every microsecond counts, and every dependency hanging off it gets questioned, because latency here is money you're leaving on the table.
• The cold path writes down what happened — fills, state changes, the durable audit trail. Its job is truth. It's allowed to be slower, because what keeps it up at night isn't latency. It's losing or corrupting the record.

One is tuned for the common case, at speed. The other is tuned to never be wrong, even when something underneath it catches fire. Ask either one to honor the other's contract and you end up with a system that's mediocre at both.

The cold path is the source of truth

Here's the rule that matters: the hot path reports to the cold path, never the reverse. The fast path does its thing and emits what it did. The durable path takes those events and becomes the authoritative record of where the system actually stands. When they disagree — and eventually they will — the cold path wins. It was built to be right. The hot path was only ever built to be quick.

That inversion is what makes the speed safe to have. The hot path gets to be aggressive, to bet on the happy case, to cut corners on its way to the venue, precisely because it's not the thing that has to stay correct when something fails. The cold path is. Once you've pulled "the thing that's fast" apart from "the thing that's true," you can push the fast one as hard as you want without putting the whole system on the line.

Strong where it moves money, eventual where it does not

The split lines up neatly with consistency. The execution path — where capital actually moves — needs strong consistency. The system has to know, with no hand-waving, what it sent and what it's holding. Reporting, analytics, monitoring? Those can be eventually consistent. Stale data on a dashboard costs you a bit of visibility for a few seconds. It doesn't cost you money.

The expensive mistake is crossing the wires: letting a money-moving decision read off an eventually-consistent path, or paying the tax of strong consistency on a dashboard nobody trades from. Honestly, knowing which side each piece of work belongs on is most of the job. Get that boundary right and the system is fast and safe at the same time. Get it wrong and you're either slow for no good reason, or fast in exactly the places you can't afford to be.

Where the two paths meet

The seam between the two is the part I worry about most, because it's where speed hands off to durability and you can't afford to drop anything in the gap. A fill happens on the hot path. It has to land on the cold path exactly once, even if the hot path falls over the instant after it emits the thing. This is where idempotency and durable event handling earn their keep. The handoff has to survive a failure on either side of it, not just the side you happened to test.

Make the fast path fast, the true path true, and never confuse which is which.

A system built this way is honest about the trade-off instead of pretending there isn't one. It's fast where speed actually gets paid for, and it's reliable where being wrong costs you real money. The line between those two got drawn on purpose, by someone, at a desk — not discovered at 3am in production because something finally went sideways. In my experience that's the whole difference between a system that holds up and a prototype that merely runs until it doesn't.

Ignacio Montoya is a systems architect specializing in algorithmic trading infrastructure, financial systems, and digital asset platforms. He designs systems that are fast where latency pays and durable where correctness counts — with the boundary drawn deliberately.