How engineering in an HFT company works

A common assumption about HFT is that it is all about shaving microseconds. That is only part of the job. In practice, the harder problems are often in system design, decision logic, and handling complexity across multiple exchanges.

At Wincent, we solve these problems mostly in Rust. That is only the technical part. The cultural part matters just as much. We expect engineers to understand why they are delivering a specific piece of work, challenge the status quo, and ship work that creates value. We say things directly, keep politics out of the way, and do not wait for a long chain of approvals to make decisions.

The technical reality: architecture over micro-optimizations

The “god emperor” of engineering isn’t necessarily the person writing the fastest assembly code. It’s the engineer who can look at the entire system, identify the actual bottleneck, and solve the right problem. Sometimes that means redesigning part of the architecture. Sometimes it means improving how systems interact across exchanges. And sometimes it means shaving microseconds off a critical path because those microseconds directly impact profitability.

Because of this, our engineering spans a wide spectrum. Some engineers work close to the metal: networking, OS-level buffers, and memory layout. Others work closer to the trading logic, translating mathematical models from quantitative researchers into robust, production-ready systems.

The expert system: translating math into production

A large part of our engineering is building the decision logic that drives our trading systems. Quants and researchers continuously discover new patterns, signals, and sources of edge. Turning those ideas into production requires close collaboration between research and engineering, from mathematical models and data processing to the systems that deliver market data and execute orders in real time.

The engineering challenge is translating those mathematical models into a robust, production-ready system that reacts to real-time input data. This isn’t a one-way ticket-taking process. Engineers collaborate directly with researchers, pushing back on what is computationally feasible, and working together to find the optimal tradeoff between a theoretically perfect model and a fast, reliable implementation.

Why we chose Rust

Because we started later than many established, traditional HFT firms, we had the opportunity to make different technology choices from day one. Rather than building on a large existing codebase, we could choose a modern toolchain that matched our needs.

Rust lets us encode domain constraints directly into the type system, so the compiler catches mistakes for us. In trading, small representational mistakes are incredibly expensive. Selling 1 Bitcoin for $100,000 is very different from selling 100,000 Bitcoin for $1. By wrapping raw numbers into strict domain types (like Price and Amount), we prevent these catastrophic mix-ups at compile time.

Threading: when to use async vs. OS threads

Rust doesn’t force a specific concurrency model on you. For many applications, an async runtime like Tokio is fantastic. It provides great developer productivity and handles high-throughput I/O beautifully using work-stealing queues.

However, in the critical path of a trading system, work-stealing queues introduce a scheduling latency penalty. If you need a continuation to be scheduled immediately and not after some random task finishes, you simply can’t afford that unpredictability. For our most latency-sensitive components, we bypass async runtimes entirely. We manage OS threads manually and pin them to specific CPU cores to ensure absolute predictability.

How the codebase is actually structured

We think of it in layers. The performance-critical parts of the system (networking, OS-level buffers, serialization) are stable. They don’t change often. They can contain unsafe code, but it’s highly localized. You can have an unsafe block where you tell the compiler “here I’m king, I’ll check everything on my own.” But that code is encapsulated behind safe APIs.

On top of that, you have the layer where we iterate fast: adding new trading strategies, connecting to new exchanges, tuning decision logic. Rust’s safety guarantees mean that a quant researcher, someone who is great at their job but isn’t a systems programmer with five years of writing memory-safe code, can write production Rust that is performant and won’t do something catastrophic.

Fireside chat: engineering culture at Wincent

We continued our conversation with Pavol, shifting from systems architecture to the day-to-day culture of the engineering team.