HermitMQ is a high performance, open source message broker written in Go, purpose built for high load systems where standard solutions introduce excessive latency and garbage collector pressure. By replacing heavyweight serialization frameworks with a custom 29 byte binary protocol, an mmap indexed Write Ahead Log, and zero copy reads, the broker surpasses 2,000,000 messages per second (over 3.4 GB/s throughput) on an Apple M1 processor.
- Source Code & Documentation: GitHub
ekhidirov/hermitmq - Tech Stack: Go (Golang), Custom Binary TCP Protocol, Write Ahead Log, Memory Mapped Files (
mmap), Zero Copy I/O, Built-in Client SDK.
Why Do Standard Brokers Become a Bottleneck?
In high load microservice architectures, traditional message brokers often hit three major bottlenecks: serialization/deserialization overhead (JSON/Protobuf), garbage collection pauses caused by constant heap allocations, and thread contention during concurrent writes to a single queue. The goal behind HermitMQ was to build an ultra fast, memory-predictable broker in pure Go with minimal response latency.
Key Architectural Decisions in HermitMQ
| System Component | HermitMQ Implementation | Business & Infrastructure Impact |
| Network Protocol | Custom 29 byte binary protocol over TCP without external serializers | Minimal network overhead and zero redundant memory allocations when parsing headers |
| Data Storage | Topic Partition model backed by a Write-Ahead Log with mmap indexed files | Instant offset lookups via memory mapped indexes and sequential disk writes |
| Network I/O | Zero Copy streaming via io.CopyN | Transfers data directly from the file buffer to the socket bypassing user space, reaching read speeds up to 3.4 GB/s |
| Concurrency Control | Lock Striping pattern (locks isolated by partition and segment) | Eliminates contention on global mutexes when dozens of producers and consumers run simultaneously |
| Fault Tolerance | Built-in Out Of Memory (OOM) protection and frame size validation | Stable operation under peak traffic without sudden node crashes caused by RAM exhaustion |
Benchmarks
Testing was conducted on a local benchmark environment (Apple Silicon M1) using the project's built in Client SDK:
- Read Throughput (Zero Copy Read): Over 2,000,000 messages per second.
- Data Bandwidth: Over 3.4 GB/s.
- Memory Footprint: Flat RAM usage profile and minimal pressure on the Go Garbage Collector thanks to a zero allocation approach on the hot path.