booblik is a message broker on the JVM built around an append-only log: a topic splits into partitions, a partition into segments, and a consumer reads by a numeric offset it keeps itself.
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.
The writer is an actor, and it has no timer
Batching writes is the obvious optimisation and the usual implementation is a timer: hold writes for 5 ms, then flush. Which means you have configured a latency floor, and you now own the job of retuning it whenever load changes.
booblik has one writer actor per partition, and it groups whatever is already in its mailbox into a single barrier. No timer, no window.
Under light load the mailbox holds one message and it goes out immediately. Under heavy load it holds hundreds and they go out together. The group size self-adjusts because it is the load, measured at the only moment that matters — the instant before the write.
Zero-copy, and what it costs
FETCH is served straight from the page cache to the socket with transferTo. The bytes never enter the JVM heap. Below that sit segments with a sparse offset index, two write paths (FileChannel and an FFM memory mapping), rolling, retention by size and by age, and recovery from a torn write.
A caught-up consumer does not poll. It waits on the broker, and a write during the wait wakes it immediately.
Every record carries a CRC32C, verified on every read that touches the bytes — which, by construction, the zero-copy path does not. That is not an oversight, it is the trade: you cannot check bytes you never look at. Saying so out loud is more useful than a footnote claiming end-to-end verification.
Two more things are absent for the same reason. TLS and compression both require transforming the bytes, and transforming them means copying them. They are not on a roadmap because they are incompatible with the design, not because nobody got to them.
Topic creation at runtime is missing on purpose too: the set of partitions is fixed at startup, which is what removes the coordinator.
Measured, not asserted
The performance claims come from a rented Linux machine with ext4 on a local disk and nothing else running — and, for the end-to-end figures, from two such machines with a 7.85 Gbit/s link between them, the broker in its own process and the load generator on the other host.
That last detail is the one that makes the numbers mean anything. A generator sharing cores with the service measures the generator; I have made that mistake elsewhere and written it up. Methodology and full tables are in docs/benchmarking.md.
What ships
A client library with a pipelined connection matched by correlation id, an accumulating producer, a topic handle that routes by key, and subscriptions as Flow<RecordBatch>.
A runnable broker with configuration validated at startup, a metrics line, retention, a distribution and a container image with its own health check — because "it runs on my laptop" and "it starts in a container with the wrong config and tells you why" are different levels of finished.
Source: github.com/youndie/booblik