High-Performance Cryptocurrency Trading Engine Development
Aishwary Dhare
Building a Crypto Exchange Engine in C++
High performance OLTP engine using low level language, in-memory data and resilient backup-restore mechanism
Photo by David McBee from Pexels
The core of an Exchange platform is its trading engine. A trading engine is a piece of software that keeps a record of all open orders in a market and generates new trades if the two orders can be fulfilled by each other.
To accommodate volatility of a crypto currency plus to deliver 24 hour availability of exchange to unlimited users. The trading engine demands a highly efficient and performant tech stack.
When the development first started for the exchange platform, there was no ‘engine’ but only an idea of a micro-service having REST APIs doing CRUD operations. We realised the necessity of developing with an ‘engine’ thought process later. Thanks to smart team I was working with and open source resources on GitHub.
The development plan for Exchange Engine received its shape by brain storming on the following questions —
Question 1: Should we use framework to develop the trade engine?
Frameworks bring in a lot of boilerplate code which are essential when building a web application for structured coding, security, scalability and easy troubleshoot
But for our specific requirements in the Trade-Engine, frameworks will only bring in extra overhead resource consumption of the machine
And we figured to improve security, we will keep our engine on a private subnet in a VPC
Question 2: Should we use CRUD based solution with SQL or NoSQL DBMS?
This was an easy elimination as with experience I knew the DBMS alone will completely consume computing capacity of the machine
Also we did not require the additional functionalities of the DBMS such as indexing
Question 3: If SQL and NoSQL DBMS are out, Can we use the In-memory database?
Redis is one of such open-source, well documented and with large community in-memory database
It has a smart crash recovery mechanism
Redis dumps its data into a file at regular intervals and Redis also keeps logs of all the operations performed on it after the dump until the next dump
When restoring, Redis first loads the last available data dump and then executes all the available operations from logs on itself. Ultimately, bringing the state of database intact and recovered after crash
Redis was proving to be the desired solution, and it also had overhead of extra functionalities which we didn’t require
Conclusion
Frameworks are not required, hence engine needs to be built as standalone to eliminate unnecessary overhead and attain maximum efficiency
To ensure high performance a low level programming language will be needed
For rapid trading all the data will be stored in Memory (RAM)
Inspired by Redis, backup-restore mechanism of Redis will be replicated using scheduled dump of data in RDBMS as regular intervals and also keeping operation logs in RDBMS
Only INSERT queries and no SELECT queries with RDBMS will keep its resource consumption affordable for the engine
Only while restoring data from RDBMS at engine boot up the SELECT queries will be used hence it will also be affordable
Result
Decided to build the Trade-Engine in C++
Using structs for custom data types, and maintaining skip-lists for quick computations for trading.
Calloc malloc ensured conservative memory usage while coding.
Pointers eliminated all the data replication that would have been impossible to attain in higher level languages. Also eliminating need of garbage collection which completely halts all processing when it runs.
Furthermore increased memory efficiency using smart implementations like using Bit-flags and Bit-masks instead of Booleans.
The engine finished after months of development and rigorous testing of business logics for the trading.
And above all the expectations it performed brilliantly and crash recovery procedure inspired from Redis worked flawlessly.
From our test results using JMeter —
Engine executed over 10,000 trades per CPU per second, proving scalability to over 1M+ transactions a second , well above the max ever ~900K peak of June 5, 2024
GIF by Bitstamp & Giphy
Like this project
Posted Jan 6, 2026
Why did I build my Exchange Engine in C? TL;DR Ultra-fast concurrent trades without data conflicts or crashes with proven scalability to 1M transactions/second
Likes
0
Views
1
Timeline
Aug 1, 2018 - Jul 31, 2019
Clients
Cryptokart
