Why did I build my 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 —

1. Question 1: Should we use framework to develop the trade engine?
   Findings:
   - 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
2. Question 2: Should we use CRUD based solution with SQL or NoSQL DBMS?
   Findings:
   - 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
3. Question 3: If SQL and NoSQL DBMS are out, Can we use the In-memory database?
   Findings:
   - 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 under a second on an AWS EC2 t2.micro instance i.e. 1 vCPU, 1GB RAM

I would love to hear from you, work together and solve complex problems. Reach me on LinkedIn at https://linkedin.com/in/aishwarydhare

Thank you for reading : )