BlazeMQ
52KB Kafka-compatible broker in C++20, zero dependencies
Details
- External ID
- 46955708
- Source
- HN
- Company
- —
- Product
- BlazeMQ
- Website domain
- github.com
- Launched
- Feb. 10, 2026
- Cohort
- —
- Upvotes
- 5
- Upvotes percentile
- 0.10512129380053908
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:26 p.m.
- Updated at
- Sept. 7, 2026, 9:26 p.m.
Description
I built a message broker that speaks the Kafka wire protocol, so any Kafka client (librdkafka, kafka-python, kcat, etc.) works without code changes. The entire binary is 52KB. No JVM, no ZooKeeper, no third-party libraries — just C++20 with kqueue/epoll. Starts in <10ms, uses 0% CPU when idle. I built this because running Kafka locally for development is painful — gigabytes of RAM, slow startup, ZooKeeper/KRaft configuration. I just wanted something that accepts produce requests and gets out of the way. Technical details: - Single-threaded event loop (kqueue on macOS, epoll on Linux) - Memory-mapped log segments (1GB pre-allocated, sequential I/O) - Lock-free SPSC/MPSC ring buffers with cache-line alignment - Kafka protocol v0-v3 including flexible versions (ApiVersions, Metadata, Produce) - Auto-topic creation on first produce or metadata request The most interesting bug I hit: librdkafka sends ApiVersions v3, which uses Kafka's "flexible versions" encoding. But there's a special exception in the protocol — ApiVersions responses must NOT include header tagged_fields for backwards compatibility. One extra byte shifted every subsequent field, causing librdkafka to compute a ~34GB malloc that crashed immediately. Current limitations: no consumer groups, no replication, single-threaded, no auth. It's v0.1.0 — consume support is next. MIT licensed, runs on macOS (Apple Silicon + Intel) and Linux.
Enrichment
- Theme
- database infrastructure and developer tools
- Vertical
- Horizontal
- Function
- Data infrastructure
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Hobby / open-source project
- Normalized one-liner
- kafka-compatible broker in c++
- Manually corrected
- False
Could you build this?
No Implementing a high-performance, zero-dependency Kafka wire protocol broker in C++20 using raw kqueue/epoll requires elite systems programming and distributed systems networking skills.
What it would actually take: Requires deep C++20 systems programming, low-level asynchronous I/O via kqueue/epoll, custom binary serialization/deserialization matching the complex Kafka protocol specifications, and custom disk-backed append-only commit logs with page-cache optimizations. A solo developer cannot vibe-code this without extensive knowledge of binary network protocols and low-level memory/socket architectures.
Discussion
1 comment analyzed.
Competitors mentioned: Kafka
Concerns raised: Startup time and memory claims disputed, Kafka native images already address stated pain points
Competitors
Other products that read as similar to this one — 72 launches clear the similarity bar, closest 8 shown.
Attention rank: #69 of 73 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 104 days after the earliest competitor.
- StreamHouse · hn · 2026-02-25 · 10 upvotes · similarity 0.51
- LavinMQ, an open-source message broker written in Crystal · hn · 2026-04-28 · 16 upvotes · similarity 0.48
- RedfireForge · ph · 2026-09-15 · 1 upvotes · similarity 0.46
- DuckDB for Kafka Stream Processing · hn · 2025-12-08 · 77 upvotes · similarity 0.45
- Sofka · hn · 2026-08-19 · 5 upvotes · similarity 0.44
- k8s-audit · ph · 2026-09-29 · 1 upvotes · similarity 0.43
- Lightweight Task queue on Erlang/OTP, SQLite-backed, no overengineering · hn · 2026-06-10 · 75 upvotes · similarity 0.43
- Streambench · hn · 2026-08-14 · 13 upvotes · similarity 0.40
Other launches for this product
- No other launches for this product.
Same idea, different domain
Nobody's really built a data infrastructure tool for Media & entertainment yet.