Why it exists
The niche is not "a Kafka replacement". It is a broker that fits in one head and one process — no ZooKeeper, no KRaft quorum, no group coordinator. Everything that makes Kafka operable as a cluster is deliberately absent; everything that makes a log fast is reproduced and measured.
What you get
- Segments with a sparse offset index, two write paths (
FileChanneland an FFM memory mapping), rolling, retention by size and age, and recovery from a torn write. - A per-partition writer actor with no timer. It groups whatever is already in its mailbox into one barrier, so the batch size is the load, measured at the instant before the write. No configured window means no latency floor to retune.
- Zero-copy FETCH straight from the page cache to the socket with
transferTo. - Long FETCH — a caught-up consumer waits on the broker instead of polling, and a write during the wait wakes it immediately.
- A client library: pipelined connections matched by correlation id, an accumulating producer, key-based routing, and subscriptions as
Flow<RecordBatch>.
What is deliberately missing
TLS and compression. Both require transforming the bytes, and transforming them means copying them — they are incompatible with the zero-copy path by construction, not merely unimplemented. Per-record CRC32C is verified on every read that touches the bytes, which the zero-copy path by definition does not; saying so is more useful than a footnote claiming end-to-end verification.
Runtime topic creation is out for the same kind of reason: the partition set is fixed at startup, and that is what removes the coordinator.
Measured, not asserted
Numbers come from a rented Linux machine with nothing else running and, for end-to-end figures, two such machines with a 7.85 Gbit/s link — the broker in its own process, the load generator on the other host. Methodology and full tables are in docs/benchmarking.md.