1

enter image description here

This architecture is designed to minimize latency with the help of busy-spinning and CPU affinity locks(meaning each producer/consumer thread running in only one core), preventing a thread from wandering between CPUs and losing time on context switching. I am going to use ZMQ for PUB/SUB architecture. On a side note : I am using lock-free ringbuffers.

deltas events : changes in the orderbook state

I really don't know if this is a very bad choice for a low latency application which is what i am going to design. Could anyone please point me why its bad ? and what are other low latency way of doing it ?

dopller
  • 291
  • 3
  • 13

1 Answers1

4

You are optimizing the wrong part of your application. Whatever micro- or nanoseconds you hope to gain by doing all this complex engineering is completely obliterated by the interfaces to and from it: WebSockets and HTTPS need tens or hundreds of milliseconds to traverse the network and then god knows how many hundreds of milliseconds on the other side to be processed.

Keep it simple: make something that works first, then think about how to optimize your IO.

Botje
  • 26,269
  • 3
  • 31
  • 41
  • yeah, but let's say if I ever wanted to switch to equities then i want to get this architecture right. – dopller Jul 13 '22 at 13:51
  • network latency definitely dominates in crypto – dopller Jul 13 '22 at 13:51
  • 1
    @dopller If you want to think about equities, then your first issue is writing a FIX client and your second issue is finding someone who is prepared to fund the costs of colocation at the exchange in order to take advantage of your super-sexy low latency trading engine. Unless you do that all the points raised by Botje still stand. – Ian Ash Jul 27 '22 at 18:04