Back
Experienced  · 

Navigating performance challenges as a C# Software Engineer at Optiver

Daniele Albanese

When we think of market making, we often associate it with low-latency C++ applications. However, many other technologies and programming languages play a crucial role in establishing Optiver as a leading global trading firm, among them being C#.

At Optiver, our success is largely attributed to our people. While trading is heavily automated, it is still driven by human decisions. To facilitate this, we developed a wide range of applications and GUIs that traders use to make informed trading decisions. These applications and GUIs are primarily written in C#.

In this blog post, we delve into the unique challenges our C# engineers face and the techniques they employ to balance responsiveness, performance, and usability in this fast-paced global trading environment.

The unique challenges of an ever evolving trading environment

Trading is an extremely fast-paced environment that requires constant and relentless innovation. As markets moved from pit trading to electronic trading at the speed of light, the amount of data generated and the resulting performance requirements have skyrocketed.

Our C# engineers must create performant GUIs that can handle large amounts of data, particularly during busy and volatile market conditions. These GUIs must be reliable and responsive to enable traders to quickly make informed decisions. Any unresponsive or crashing applications in this fast-paced environment could lead to significant monetary loss.

As markets continue to evolve, so do our trading strategies and GUIs. Our C# engineers must be flexible and capable of navigating the diverse technical challenges that arise. This requires not only a deep understanding of the language, but also the ability to make strategic decisions regarding its implementation. This results in fast and continuous iteration cycles as we keep innovating and expanding our trading operations.

Go beyond the language

At Optiver, we firmly believe that proficiency in a single programming language, such as C#, does not define who you are as an engineer. While expertise in a chosen language is required, what sets apart a great, performance-oriented engineer is their drive to go beyond the confines of that language.

Creating a performant application involves much more than just writing fast code. It requires interacting with the operating system correctly, understanding the hardware on which you’re running, and efficiently using the network resources at your disposal. You have to be ready to debug complex systems that extend beyond your application, ensuring that the entire stack operates efficiently.

Leveraging problem-solving and technical expertise

While our C# engineers work in tandem with a wide variety of teams, one of their main counterparts are traders. Traders constantly monitor the market and devise new strategies, so they approach our engineers with open-ended challenges. Optiver’s engineers must thoroughly understand these real-world trading problems and translate them into performant software solutions that seamlessly integrate into our systems. This process requires a comprehensive understanding of C#, creative problem-solving skills, system architecture knowledge, and the ability to translate high-level problems into practical solutions.

While trading and engineering work together closely, it is up to our engineers to develop innovative solutions that balance our strict performance requirements with elegantly simple and sustainable software solutions. These solutions must be not only performant for today’s demands but also for tomorrow’s.

Real-life example: 4x performance improvements

Over the years, one of the main trading GUIs started to show signs of a slowdown. The first step to identify the causes of this slowdown involved extensive monitoring and debugging of the application to pinpoint bottlenecks, rather than blindly undertaking a complete rewrite of the entire interface.

When the GUI was first created, it needed to handle significantly less market data as Optiver traded only a couple thousand instruments. Over time, Optiver’s trading volume grew significantly, encompassing hundreds of thousands of instruments, all of which streamed their data into the GUI. The GUI’s performance optimizations were initially focused on application-specific methods, like simple multi-threading, instead of a comprehensive view of the entire system.

The solution, both simple and elegant, drew inspiration from the concept of foveated rendering used in the graphics rendering space. Even though a trader interacted with only a portion of all instruments on the GUI at any given time, the application consistently updated the prices of all subscribed instruments. This approach led to a host of unnecessary UI updates and processing of data that the trader would never see.

To solve this issue, one of our C# engineers proposed the creation of a separate, centralized backend that would handle data subscription. However, the GUI would only receive processed data that was visible to the trader. As the trader interacted with the GUI, for instance scrolling through option strikes, the backend would stream in the required data, and unsubscribe from anything that moved out of view. This process is transparent to the trader and greatly reduces the load on the GUI, making it massively more responsive. The graphs below demonstrate this improvement.

On the left, we can see the CPU usage of the GUI before this update, and on the right, after the update.

The significance of this improvement cannot be overstated. It not only improved the performance of the GUI itself, but it also freed up more CPU resources for numerous other apps, between 20 to 40, that traders run simultaneously. There were no more complaints about slowdowns or crashes, allowing the traders to focus on executing successful trades instead of wrestling with software issues.

We saw an even more drastic improvement when it came to RAM consumption, which reduced significantly due to loading much less data. To achieve this level of performance increase, it was crucial that the engineer didn’t view the GUI in isolation. Instead, they stepped outside of this sphere, viewed the system as a whole, and optimised the entire problem, not just the GUI.

This real-life example is a testament to the way our engineers approach problem-solving: with an acute focus on performance, a deep understanding of the broader system and a drive to innovate.

As markets evolve and trading strategies become more complex, our C# engineers will continue playing a key role in delivering innovative, reliable and efficient solutions. Their deep technical expertise, coupled with their capacity to translate real-world trading challenges into high-performance software, will continue to empower our traders and fuel Optiver’s success.

Apply now

Are you ready to apply your C# expertise in a high-performance trading environment?

ExperiencedLife at Optiver
Insights

Related Articles

  • Technology

    UI as a Systems Problem

    When something feels slow, you’re probably looking in the wrong place. UI issues are rarely local and are often caused by how data is fetched, recomputed, and duplicated across the system, becoming visible only when multiple services, queries, and interactions run at the same time. Read how Optiver approaches building systems where UI and data are tightly coupled.

    Learn more
    Global
  • Technology

    Infrastructure-as-Code for Latency-Critical Bare Metal Systems

    About the Speaker Leanne Fok is a Senior Infrastructure Engineer in Amsterdam with 15+ years at Optiver. She previously led the Infrastructure Platform team responsible for our internal Infrastructure-as-Code stack and is now leading the Infrastructure Kubernetes project. Infrastructure-as-Code is straightforward in the cloud. But what about on bare metal? In her PyLadies talk, “Infrastructure-as-Code […]

    Learn more
    Global
  • Technology

    Building visibility into a CI platform

    This article explores how we operate a CI platform on fixed hardware, where auto-scaling is not always an option. It covers how we built visibility into queue times, utilisation, and system behaviour to manage capacity with confidence.

    Learn more
    Global
  • Technology

    When Speed and Scale Collide

    Data systems are often described along two axes: speed and scale. In practice, “speed” usually means some combination of latency and throughput, and systems are often optimized for one at the expense of the other, sometimes by trading efficiency for raw capacity. Those distinctions tend to break down quickly once systems move beyond simple use […]

    Learn more
    Global
  • Experienced, Meet the team, Trading

    Inside Optiver’s Institutional Trading Team

    Ask five Institutional Traders how they got here, and you'll get five different answers. Traders from Optiver’s Institutional team share their diverse paths, how they use their unique backgrounds every day, and practical advice for anyone considering the role.

    Learn more