Deep dives into the systems behind low-latency and high-frequency trading — JVM and GC internals, lock-free C++, the kernel and the network card, and the data tooling around them. Written from the perspective of an engineer working toward the top trading firms. New here? Start with Lock-free SPSC ring buffer — the queue under every trading system — or Mechanical sympathy for how the hardware really behaves, then browse the archive.

Lock-free SPSC ring buffer: the queue under every trading system
A single-producer/single-consumer ring buffer is the fastest way to move data between two threads — and the canonical low-latency interview question. We build one in C++, prove it correct with acquire/release ordering, and then watch a textbook false-sharing ‘fix’ make it slower before the real optimisation takes it 14× faster. All numbers measured and ThreadSanitizer-clean.

Multi-producer lock-free queues: CAS, sequence numbers, and why they don't scale
The SPSC ring buffer was easy because each cursor had exactly one writer. Add a second producer and that assumption — and the whole design — breaks. We fix it with Vyukov’s per-cell sequence-number queue, prove it correct under ThreadSanitizer, and then measure something every low-latency engineer should internalise: making it ’lock-free’ does not make it scale.

Mechanical sympathy: cache, branches, false sharing
Three hardware ideas that decide whether your low-latency code is fast or pretending to be: how the cache hierarchy works, why branch prediction can change runtime by 5×, and how false sharing makes lock-free code slower than mutexes.

The single-writer principle
A short walk through the single-writer principle: why exactly one thread should mutate a piece of state, why this is faster than ‘real’ lock-free code in most cases, and how the Disruptor pattern operationalises it.

Generational ZGC, end to end
A walk through Generational ZGC: coloured pointers, load and store barriers, the generational split landed in JDK 21, and how it hits sub-millisecond pauses on multi-TB heaps.

Order-book data structures: the ADT, the array ladder, and the tradeoffs
How matching engines store and update the limit order book — sorted maps, array+bitmap ladders, hash+list, and the production tradeoffs — with a reference Java implementation.