Skip to content
All case studies

Financial services / Quantitative trading · 10 months

Replacing a C# monolith with a low-millisecond market-data platform

A quantitative trading firm

The challenge

The firm made markets through a monolithic legacy system that had outgrown itself. It still worked, but it had become the ceiling on everything: a single codebase that was hard to change, harder to scale, and impossible to reason about under load. New strategy ideas died not because they were bad but because there was nowhere to put them.

To move forward the firm needed three things at once: real-time market data from multiple exchanges, a robust historical data foundation to research and back-test against, and the observability that live trading at low-millisecond latencies demands. The existing architecture offered none of them, and at trading latencies the usual “just add a queue” answers do not survive contact with reality.

Our approach

We led the migration of the market-making system from a monolithic C# architecture to a Python-based microservices design, deployed via Docker with RabbitMQ carrying asynchronous communication between services. Decoupling the monolith into services was what made every later improvement (and every new product) possible.

For the hot path we did not compromise: we designed and built a high-throughput real-time market data ingestion system in Rust and Redis, processing live order-book and trade data from multiple exchanges at low-millisecond end-to-end latencies. Rust gave us the predictable performance the trading desk needed without the operational footguns of hand-tuned C++.

Alongside the live feed we built a historical data pipeline that combined real-time streaming, polling and archival: TimescaleDB for efficient querying of terabytes of historical data, and S3 with Parquet for scalable, cheap cold storage. One pipeline now feeds both live trading and offline research from a single, consistent record.

Finally we made the whole thing legible. Monitoring and alerting on Prometheus and Grafana track market anomalies, system health and trading-strategy performance in real time, so the desk and the engineers are looking at the same picture rather than arguing about whose number is right.

What we delivered

  • A migration from a C# monolith to Python microservices on Docker, with RabbitMQ for asynchronous inter-service messaging.
  • A Rust and Redis market-data ingestion layer handling multi-exchange order-book and trade data at low-millisecond latency.
  • A unified historical pipeline: TimescaleDB for hot queries, S3 and Parquet for terabyte-scale cold storage.
  • Real-time monitoring and alerting on Prometheus and Grafana for market anomalies, system health and strategy performance.
They thought like traders, not contractors. The new platform paid for itself the first time we shipped a strategy the old one could never have held.
Head of Trading Technology

Outcome

The fragmented C# monolith was replaced by a unified Python microservice platform: new product development became feasible on the same foundation, where before it had stalled.

Multi-exchange market-data ingest now runs at low-millisecond end-to-end latency, fast enough to trade on.

A terabyte-scale historical store stands ready for back-testing, strategy research and compliance retrieval, all from one source of truth.

Financial services / Quantitative trading · 10 months

Replacing a C# monolith with a low-millisecond market-data platform

A quantitative trading firm

The challenge

The firm made markets through a monolithic legacy system that had outgrown itself. It still worked, but it had become the ceiling on everything: a single codebase that was hard to change, harder to scale, and impossible to reason about under load. New strategy ideas died not because they were bad but because there was nowhere to put them.

To move forward the firm needed three things at once: real-time market data from multiple exchanges, a robust historical data foundation to research and back-test against, and the observability that live trading at low-millisecond latencies demands. The existing architecture offered none of them, and at trading latencies the usual “just add a queue” answers do not survive contact with reality.

Our approach

We led the migration of the market-making system from a monolithic C# architecture to a Python-based microservices design, deployed via Docker with RabbitMQ carrying asynchronous communication between services. Decoupling the monolith into services was what made every later improvement (and every new product) possible.

For the hot path we did not compromise: we designed and built a high-throughput real-time market data ingestion system in Rust and Redis, processing live order-book and trade data from multiple exchanges at low-millisecond end-to-end latencies. Rust gave us the predictable performance the trading desk needed without the operational footguns of hand-tuned C++.

Alongside the live feed we built a historical data pipeline that combined real-time streaming, polling and archival: TimescaleDB for efficient querying of terabytes of historical data, and S3 with Parquet for scalable, cheap cold storage. One pipeline now feeds both live trading and offline research from a single, consistent record.

Finally we made the whole thing legible. Monitoring and alerting on Prometheus and Grafana track market anomalies, system health and trading-strategy performance in real time, so the desk and the engineers are looking at the same picture rather than arguing about whose number is right.

What we delivered

  • A migration from a C# monolith to Python microservices on Docker, with RabbitMQ for asynchronous inter-service messaging.
  • A Rust and Redis market-data ingestion layer handling multi-exchange order-book and trade data at low-millisecond latency.
  • A unified historical pipeline: TimescaleDB for hot queries, S3 and Parquet for terabyte-scale cold storage.
  • Real-time monitoring and alerting on Prometheus and Grafana for market anomalies, system health and strategy performance.
They thought like traders, not contractors. The new platform paid for itself the first time we shipped a strategy the old one could never have held.
Head of Trading Technology

Outcome

The fragmented C# monolith was replaced by a unified Python microservice platform: new product development became feasible on the same foundation, where before it had stalled.

Multi-exchange market-data ingest now runs at low-millisecond end-to-end latency, fast enough to trade on.

A terabyte-scale historical store stands ready for back-testing, strategy research and compliance retrieval, all from one source of truth.

Working on something similar?