Architecture & ModernizationConference50min
From a startup stack to 5 microseconds: inside a crypto trading engine
Bitvavo rebuilt its live crypto exchange core for deterministic, replayable, low-latency processing. Replacing database-centered architecture with an ordered log, replicated state machine, Raft, and reliable UDP delivered sub-millisecond latency and 100,000 orders/second, while balancing correctness, operational complexity, and JVM performance constraints.
talk.summaryAiDisclaimer
Oleg LobanovBitvavo
talkDetail.whenAndWhere
Thursday, October 8, 17:40-18:30
TBA 5
talks.roomOccupancytalks.noOccupancyInfo
What does it take to rebuild the core of a crypto exchange while it is already operating 24/7?
In 2018, Bitvavo's exchange ran on a familiar startup stack: Node.js, Go, Redis, MySQL, and Kafka. It helped the company move fast and grow, but as trading volume increased, the same architecture began to show its limits. Latency became harder to predict, shared infrastructure became a bottleneck, and proving correct order processing became just as important as making it fast.
This talk is the story of how we rebuilt the exchange core into a deterministic, replayable, low-latency trading platform. We moved away from database-centered processing and redesigned the system around an ordered log, a replicated state machine, Raft consensus, and a reliable UDP transport.
I'll share the engineering trade-offs behind that migration: where determinism helps, where it hurts, what changes when state lives in memory, and how far you can push the JVM when garbage collection, networking, and operating-system noise are all part of the latency budget.
The result is a production system with sub-millisecond end-to-end latency, around 5 microseconds of internal processing time, and capacity for 100,000 orders per second. But the real story is not just the numbers — it is what we had to unlearn, redesign, and operationalize to make a financial system both fast and correct.
In 2018, Bitvavo's exchange ran on a familiar startup stack: Node.js, Go, Redis, MySQL, and Kafka. It helped the company move fast and grow, but as trading volume increased, the same architecture began to show its limits. Latency became harder to predict, shared infrastructure became a bottleneck, and proving correct order processing became just as important as making it fast.
This talk is the story of how we rebuilt the exchange core into a deterministic, replayable, low-latency trading platform. We moved away from database-centered processing and redesigned the system around an ordered log, a replicated state machine, Raft consensus, and a reliable UDP transport.
I'll share the engineering trade-offs behind that migration: where determinism helps, where it hurts, what changes when state lives in memory, and how far you can push the JVM when garbage collection, networking, and operating-system noise are all part of the latency budget.
The result is a production system with sub-millisecond end-to-end latency, around 5 microseconds of internal processing time, and capacity for 100,000 orders per second. But the real story is not just the numbers — it is what we had to unlearn, redesign, and operationalize to make a financial system both fast and correct.
Oleg Lobanov
Oleg Lobanov is a Staff Engineer at Bitvavo, where he works on the core trading platform behind roughly half of Europe's euro-denominated spot crypto volume. He brings two decades of software engineering experience — more than ten years of it building low-latency trading systems and high-scale e-commerce platforms. His focus is the JVM, distributed systems, and the kind of performance engineering where microseconds and determinism genuinely matter.