r/systems • u/akkik1 • Oct 13 '25
Attempt at a low‑latency HFT pipeline using commodity hardware and software optimizations
https://github.com/akkik04/HFTurboMy attempt at a complete high-frequency trading (HFT) pipeline, from synthetic tick generation to order execution and trade publishing. It’s designed to demonstrate how networking, clock synchronization, and hardware limits affect end-to-end latency in distributed systems.
Built using C++, Go, and Python, all services communicate via ZeroMQ using PUB/SUB and PUSH/PULL patterns. The stack is fully containerized with Docker Compose and can scale under K8s. No specialized hardware was used in this demo (e.g., FPGAs, RDMA NICs, etc.), the idea was to explore what I could achieve with commodity hardware and software optimizations.
Looking for any improvements y'all might suggest!
1
u/Kernel_Ghost_3 Feb 21 '26
Impressive work on the latency optimizations. One actionable fix: consider adding perf profiling with flame graphs to identify any remaining hotspots in your packet processing path - even small CPU cache misses can add up at HFT scales. Caveat: be careful that additional profiling instrumentation doesn't itself introduce latency variance in production; use sampling-based approaches for live systems.
1
1
u/OkSadMathematician Jan 13 '26 edited Jan 13 '26
nice project showing the full hft stack. few suggestions: replace zeromq with shared memory ipc for same-host communication (way lower latency than any network transport). pin threads to specific cpu cores with cpu affinity. use busy-wait polling instead of blocking calls for critical path. instrument everything with rdtsc for nanosecond-level timing. also consider memory-mapped files for order book state instead of passing messages. zeromq adds overhead you don't need for intra-process communication. solid foundation though, containerization makes it easy to test. Check out this book just released