I was in this area from 2003 to 2013. Can't think of any reading materials, but it all boils down to ultra low latency (think < 100 microseconds within the local network) and high volumes (think > 30,000 transactions per second). The state of the art may have moved since then, but:
1) Network layer: raw TCP sockets with binary packed messages (sometimes structs directly cast to and from raw buffers, keeping network/host byte order in mind); separate message data dictionary to avoid metadata overhead inside messages.
2) Processing: optimised C++ code; pointers; multi-threaded processes that utilise all available cores; minimal locking and contention between threads (queues with spin locks and bulk transfers); threads directly bound to CPU cores (prevent context switching overhead); prevent heap locks by allocating large object pools at startup;
3) Disk I/O: minimise disk I/O in logic-heavy, low latency threads; application level in-memory disk write queues; prefer append mode writes; application level in-memory caches (basically hash maps of reference data loaded at startup)
4) None of the "trendy" programming practices: no OOP design patterns; no dependency injection; functional programming, but without fluent APIs;
5) No popular frameworks: internally developed solutions optimised for our specific use cases, instead of off the shelf libraries or frameworks (e.g. the messaging middleware was in-house)
There is more, but this is what I could think of, off the top of my head.
1) Network layer: raw TCP sockets with binary packed messages (sometimes structs directly cast to and from raw buffers, keeping network/host byte order in mind); separate message data dictionary to avoid metadata overhead inside messages.
2) Processing: optimised C++ code; pointers; multi-threaded processes that utilise all available cores; minimal locking and contention between threads (queues with spin locks and bulk transfers); threads directly bound to CPU cores (prevent context switching overhead); prevent heap locks by allocating large object pools at startup;
3) Disk I/O: minimise disk I/O in logic-heavy, low latency threads; application level in-memory disk write queues; prefer append mode writes; application level in-memory caches (basically hash maps of reference data loaded at startup)
4) None of the "trendy" programming practices: no OOP design patterns; no dependency injection; functional programming, but without fluent APIs;
5) No popular frameworks: internally developed solutions optimised for our specific use cases, instead of off the shelf libraries or frameworks (e.g. the messaging middleware was in-house)
There is more, but this is what I could think of, off the top of my head.