Financial systems · Rust in progress

Karthik Ravikanti

18 years in financial systems and network protocols

Karthik's background spans financial trading systems, market connectivity, network protocols, payment backends, and C++. His Rust matching-engine project can connect those domains: a network edge receives orders, while a separate core applies market rules.

The page shows the project's intended technical direction. The current implementation remains early, so planned architecture and completed code are called out separately below.

Why this project

Apply market-systems experience to a new Rust domain

Karthik has worked around financial backends, exchange connectivity, and network protocols. A matching engine gives those ideas a concrete core: incoming orders compete for execution according to explicit price and time rules.

He had not built a matching engine or a low-latency Rust system before this project. That makes the work a useful bridge between domain familiarity and new implementation decisions in Rust, from owned order data to deterministic state changes.

18 yrs
Financial systems experience
Rust
Payment backend experience
Network
Protocols and market connectivity
In progress
Rust matching engine
The design challenge

Connect network systems without coupling them to matching

A network-facing trading system must turn incoming bytes into valid orders before the matching core can make decisions. Message framing, malformed input, and disconnect behavior belong at that boundary.

The matching engine then owns price priority, FIFO order, and trade decisions. Keeping those responsibilities separate makes both sides easier to reason about and test.

Target architecture · planned

From network message to matched order

This is the intended system shape, not a claim about code already shipped.

  1. 01

    Network edge

    Receive and frame messages; handle partial reads and disconnects.

  2. 02

    Validated orders

    Parse input and convert it into explicit order types.

  3. 03

    Matching core

    Apply FIFO price levels, multi-price matching, and cancellation.

  4. 04

    Trade output

    Emit deterministic results, then measure throughput and latency.

Implemented so far

A CSV-backed single-match baseline

The current code covers one buy order meeting one sell order from CSV input. FIFO price levels, a multi-price book, network transport, and performance measurements remain planned work.

Potential network phase

Turn protocol experience into a testable Rust boundary

Network work can give the project a second systems layer after the single-process matching rules settle. The adapter would own transport concerns, validate incoming messages, and pass typed commands into the engine. The matching core would stay independent of sockets and wire formats.

That separation creates concrete Rust questions: who owns a decoded message, how malformed input is rejected, what a full queue does to a fast sender, and how the system responds when a connection closes mid-message. These are future design topics. No protocol, socket implementation, or network benchmark is claimed as complete.

[ Network boundary ]

Keep protocol handling outside the matching rules

Karthik brings experience with C++ network protocols and market connectivity. A natural next design step is to place a narrow network adapter in front of the matching engine, so byte streams and message framing do not shape the core order book.

That boundary can make partial reads, framing, validation, and disconnect handling explicit. If the chosen transport is a byte stream, the adapter must reconstruct complete messages from arbitrary read chunks. The transport and wire protocol are not selected yet; these are design questions for a later phase, not completed features.

[ Matching core ]

Make price-time priority deterministic

The planned core grows from one buy meeting one sell into FIFO queues at price levels, a multi-price book, cross-price matching, and order cancellation.

Starting with deterministic matching rules gives later network and performance work a clear contract. A repeatable input should always produce the same ordered trade results. Benchmarking and threading stay future work until the book behavior is stable.

The journey

One clear path through the build

Drag to explore · Select a milestone to read the full story

More client journeys

See another path into Rust

Ready to Land a $80k+ Rust Job in the US or Europe?