ack after storage today
Every batch is durably persisted to S3/MinIO or the file system BEFORE the producer is acknowledged. No loss between “accepted” and “saved” — by construction.
Roxa does not tie data to the disk of a particular broker. Instead, writes are grouped in memory and durably persisted to object storage — the diskless model. This yields two properties: the broker is near-stateless (if it dies, a new one starts and reads from S3), and the acknowledgement arrives only after the data is actually written. Below is the path of a message.
Messages are accepted and each gets a monotonic offset — ordering within a partition is guaranteed.
Writes from many producers accumulate in memory for a few dozen milliseconds, avoiding thousands of tiny storage requests.
The accumulated batch goes to S3/MinIO as a single object and becomes durable.
The producer gets its ack only once the object is committed to storage. There is no gap between “accepted” and “saved”.
Every batch is durably persisted to S3/MinIO or the file system BEFORE the producer is acknowledged. No loss between “accepted” and “saved” — by construction.
A mode with a local write-ahead log for even faster acks at the same durability — for scenarios with strict latency requirements.
You choose the storage: S3/MinIO or the local file system — a single config parameter.
| Roxa | Apache Kafka | Redpanda | |
|---|---|---|---|
| Data storage | S3 (diskless) | Broker disks | Disks + tiered |
| Runtime | Rust, no JVM | JVM + ZK/KRaft | C++ |
| Loss on node failure | None — data is in S3 | Possible before replication completes | Possible |
| Getting started | A single binary | Cluster + coordination | Cluster |
| Kafka clients | Yes | Yes | Yes |
| Cost of ownership | Perpetual license, minimal operations | Free + an operations team | Enterprise subscription from a US vendor |
Latency depends on the durability mode and the storage: tens of milliseconds on local NVMe/MinIO, higher on remote S3. We do not promise numbers we cannot keep.