HermitMQ's million-message claim rests on a 29-byte header, not the network

A Go developer has published a writeup of HermitMQ, a message broker he says reaches a throughput of a million messages per second, and his diagnosis is worth more than his number: the wall in Go is the garbage collector, not the socket [s1c1][s1c2]. That matters because the remedies he describes are cheap and portable to anything you are already running: a fixed binary header instead of JSON, pooled buffers, and reads served straight from file to socket [s1c3].

The argument is that once you are past a few hundred thousand messages per second, parsing each one with standard JSON allocates a large number of small objects, the collector wakes too often, and you pay for it in CPU time and latency spikes [s1c2]. So he dropped standard serialization entirely and packs every message into a header of exactly 29 bytes: one magic byte, eight bytes of nanosecond timestamp, eight bytes of offset, four each for key size and payload size, and four for a record count to support batching [s1c4][s1c5]. Those field widths add up to the stated 29 [s1c6]. The magic byte is used for version checking and for discarding bad packets immediately, and the broker writes the offset itself so ordering is its property rather than the client's [s1c7][s1c8]. Reading is done with the binary package, with buffers reused through sync.Pool, which he says yields practically zero allocation under standard loads [s1c9].

The useful part of the post is that he does not stop at that sentence. He states plainly that the allocation win is one-sided: consumer delivery is clean, but the decode path from producers still calls make on a slice sized to the payload for every message [s1c10][s1c11]. At the headline rate, that is on the order of a million heap allocations per second on the ingest side [s1c12]. The GC has been moved off half the data path, not removed from it.

Delivery is where he claims the bigger effect. On a client request the broker locates the offset in the log file, wraps it in a section reader, and hands it to io.CopyN with the connection as the destination, so the bytes go from the file to the consumer socket without being read into program memory first [s1c13][s1c14]. That is asserted rather than demonstrated in the material supplied here; there is no syscall trace, and the promised benchmark numbers do not appear in the portion of the text available to me [s1c15]. Anyone adopting the pattern should confirm the copy actually takes the kernel fast path with their Go version and their file and connection types, because the whole claim collapses into an ordinary buffered copy if it does not.

The storage design is conventional in a good way. Everything lands in a write-ahead log split into segments, each with a .wal file of raw data and an .idx file mapping offsets to physical bytes, with the indexes mmapped so lookups are a binary search in memory [s1c16][s1c17]. Background compaction deduplicates by key [s1c18]. On startup the broker scans the WAL, and if a header claims more bytes than the file physically contains it treats the write as interrupted and truncates the torn tail with os.Truncate rather than failing the segment [s1c19][s1c20].

Two things to watch. First, whether the planned move to zero-serialization access, reading byte offsets directly in the network buffer without unpacking into Go structs, actually ships, since that is what would close the producer-side allocation gap [s1c21]. Second, whether benchmark methodology follows the code, which is on GitHub [s1c22]: batch size, fsync policy, and whether producer and consumer ran on the same machine decide what the million means. Header overhead alone is 29 MB/s of non-payload bytes at that rate [s1c23].